Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix broken links #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix broken links #2

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions guide-to-oauth2-grants.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -194,18 +194,18 @@ A third party client is a client that you don't trust.

An access token represents a permission granted to a client to access some protected resources.

If you are authorizing a machine to access resources and you don't require the permission of a user to access said resources you should implement the [client credentials grant](/authorization-server/client-credentials-grant/).
If you are authorizing a machine to access resources and you don't require the permission of a user to access said resources you should implement the [client credentials grant](#client-credentials-grant--section-44).

If you require the permission of a user to access resources you need to determine the client type.

### Client Type?

Depending on whether or not the client is capable of keeping a secret will depend on which grant the client should use.

If the client is a web application that has a server side component then you should implement the [authorization code grant](/authorization-server/auth-code-grant/).
If the client is a web application that has a server side component then you should implement the [authorization code grant](#authorisation-code-grant-section-41).

If the client is a web application that has runs entirely on the front end (e.g. a single page web application) you should implement the [password grant](/authorization-server/resource-owner-password-credentials-grant/) for a first party clients and the [implicit grant](/authorization-server/auth-code-grant/) for a third party clients.
If the client is a web application that has runs entirely on the front end (e.g. a single page web application) you should implement the [password grant](#resource-owner-credentials-grant-section-43) for a first party clients and the [implicit grant](#implicit-grant-section-42) for a third party clients.

If the client is a native application such as a mobile app you should implement the [password grant](/authorization-server/resource-owner-password-credentials-grant/).
If the client is a native application such as a mobile app you should implement the [password grant](#resource-owner-credentials-grant-section-43).

Third party native applications should use the [authorization code grant](/authorization-server/auth-code-grant/) (via the native browser, not an embedded browser - e.g. for iOS push the user to Safari or use [SFSafariViewController](https://developer.apple.com/library/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/), <u>don't</u> use an embedded [WKWebView](https://developer.apple.com/library/ios/documentation/WebKit/Reference/WKWebView_Ref/)).
Third party native applications should use the [authorization code grant](#authorisation-code-grant-section-41) (via the native browser, not an embedded browser - e.g. for iOS push the user to Safari or use [SFSafariViewController](https://developer.apple.com/library/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/), <u>don't</u> use an embedded [WKWebView](https://developer.apple.com/library/ios/documentation/WebKit/Reference/WKWebView_Ref/)).