As highlighted in the previous post ( https://www.jstack.io/post/oauth2-0-in-a-nutshell) the OAUTH2.0 standard supports different flows depending on the usecase. Below is an overview of when to use each flow from a delegation(authorization perspective).
During the second part of this post we will focus on Open Id Connect flows which enhance the OAUTH2.0 authentication part.
Credit for part of the flow charts below go to
Dr. Philippe De Ryck( https://pragmaticwebsecurity.com/ )
Client Credential Grant Flow
Use-case: Service to Service communications
With machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on your back-end, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4), in which they pass along their Client ID and Client Secret to authenticate themselves and get a token. (https://auth0.com/docs/flows/concepts/client-credentials)
In this case the client credentials are client secret and client id. The client secret and client id can be obtained from the application registration portal of the specific service provider during the registration process.
This could be a typical use case for API-API communication, especially in a micro service architecture.
The client can use the access token(bearer token) for as long as it expires. Once expired the client can acquire a new access token using the client id and client secret.
All communications between the client-authorizaton server-resource server have to be encrypted/HTTPS.
Ideally the lifetime of the bearer token should be limited to a couple of hours and even more limited by the number of usages depends on the usecase.
Summary:
CLIENT CREDENTIALS GRANT:
- DIRECT ACCESS BY THE CLIENT APPLICATION
- ACCESS TOKEN OBTAINED USING CLIENT CREDENTIALS(CLIENT ID & CLIENT SECRET)
Authorization Code Grant Flow
Use-case: Web applications with a backend and a frontend
Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow (defined in OAuth 2.0 RFC 6749, section 4.1), which exchanges an Authorization Code for a token. Your app must be server-side because during this exchange, you must also pass along your application's Client Secret, which must always be kept secure, and you will have to store it in your client.
The interactions goes as below:
1.The user clicks Login within the regular web application.
2. OAUTH2 SDK provider redirects the user to the Authorization Server (/authorize endpoint).
3. Authorization Server redirects the user to the login and authorization prompt.
4.The user authenticates using one of the configured login options and may see a consent page listing the permissions Authorization Server will give to the regular web application.
5. Authorization Server redirects the user back to the application with an authorization code.
6. OAUTH2 provider SDK sends this code to the Authorization Server (/oauth/token endpoint) along with the application's Client ID and Client Secret.
6'.Authorization Server verifies the code, Client ID, and Client Secret and replies with an Access Token (and optionally, a Refresh Token).
7.Your application can use the Access Token to call an API to access information about the user.The API responds with requested data.
When the access token expires the client can use the client secret+client id+refresh token in order to get a new access token. Ideally the refresh tokens can life for a much longer period than the access tokens, up to months or even years. The user will be prompted to login again only when the refresh token is expired.
Summary:
AUTHORIZATION CODE GRANT
- DELEGATED ACCESS TO A BACKEND APPLICATION
- ACCESS TOKEN OBTAINED BY EXCHANGING CODE WITH CLIENT CREDENTIALS
- REFRESH TOKEN CAN BE USED WITH CLIENT CREDENTIALS
Implicit Grant flow
Use case: Single Page Applications
Basically in this flow the username and password is exchanged with an access token.
The interactions goes as below:
1. The user clicks Login within the SPA. SDK redirects the user to the Auth0 Authorization Server (/authorize endpoint) passing along a response_type parameter that indicates the type of requested credential.
2. Your Authorization Server redirects the user to the login and authorization prompt.
3. The user authenticates using one of the configured login options. Authorization server requires a consent page listing the permissions that you are given.
4.Your Auth0 Authorization Server redirects the user back to the SPA with any of the following, depending on the provided response_type parameter (step 2):
ID Token(more on ID Token later in this post)
Access Token
ID Token and an Access Token
5.Your SPA can use the Access Token to call an API.The API responds with requested data.
The Implicit flow was a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step.
It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.
Public clients such as native apps and JavaScript apps should now use the authorization code flow with the PKCE extension instead.(More PKCE later in this post)
The OAuth 2.0 Security Best Current Practice document recommends against using the Implicit flow entirely, and OAuth 2.0 for Browser-Based Apps describes the technique of using the authorization code flow with PKCE. ( https://oauth.net/2/grant-types/implicit/ )
IMPLICIT GRANT
- DELEGATED ACCESS TO A FRONTEND APPLICATION
- ACCESS TOKEN DIRECTLY OBTAINED THROUGH THE REDIRECT
- NOT SUPPOSED TO HAVE ACCESS TO REFRESH TOKENS
-DEPRECATED, USED ONLY DURING THE EARLY DAYS
-USE PKCE
Resource Owner Password Grant(Deprecated)
Since the Resource Owner Password Grant (ROPG) flow involves the client handling the user's password, it must not be used by third-party clients. In this flow, the user's username and password are exchanged directly for an Access Token.
Only consider using it when there is a high degree of trust between the user and the application and when other authorization flows (such as redirect-based flows) are not available.
Instead, OAUTH2 providers such as Microsoft, Auth0 recommends:
For confidential clients, use the Authorization Code Flow.
For public clients, use the Authorization Code Flow with PKCE.
For Single-Page Applications and Native/Mobile Apps, use web flows.
PKCE-Proof key for code exchange
Use case: Public clients(Native Apps, mobile apps, SPA)
The Proof Key for Code Exchange (PKCE, pronounced pixie) extension describes a technique for public clients to mitigate the threat of having the authorization code intercepted. The technique involves the client first creating a secret, and then using that secret again when exchanging the authorization code for an access token. This way if the code is intercepted, it will not be useful since the token request relies on the initial secret.
The full spec is available as RFC7636.
DETAILS OF THE PKCE-BASED AUTHORIZATION CODE GRANT FLOW
• PKCE allows public clients to run a more secure Authorization Code Grant
• Even though the client is public, it is still expected to be a secure environment
• Native applications were the primary target, but the same advice extends to SPAs as well
• Refresh tokens are optional, but their use cannot be protected with the client secret
• It is crucial to ensure that the right client exchanges the authorization code
• Instead of using client credentials, PKCE uses a code challenge and code verifier
• The code verifier is a cryptographically secure random string
• Between 43 and 128 characters of this character set: [A-Z] [a-z] [0-9] - . _ ~
• The code challenge is a SHA256 hash of the code verifier
• The hash function uniquely connects the code challenge to the code verifier
• The code verifier cannot be derived from the code challenge
Comments