| Endpoint | Example | Purpose |
|---|---|---|
| Authorization | https://<auth-server>/oauth/authorize | used by the client application to obtain authorization grant from the resource owner via user-agent redirection |
| Token | https://<auth-server>/oauth/token | used by the client application to exchange an authorization grant for an access token, typically with client authentication |
| Redirection | https://<client>/callback | used by the authorization server to return responses containing authorization grants to the client via the resource owner user-agent |
| Flow | Front channel | Back channel |
|---|---|---|
| Authorization code flow | ✅ | ✅ |
| Implicit flow | ✅ | ❌ |
| Resource owner password credentials flow | ❌ | ✅ |
| Client credentials flow | ❌ | ✅ |
-
server to server / machine to machine (BC)
- exchange of auth-code into an access token
- for security reasons, so that browsers cannot leak the access token
- trust relationship between the servers must exist
- secret "keys" cannot leak from the server(s)
- client id + client secret enables server to perform token exchange
-
browser to server (FC)
- full page redirects
- client id enables client to init OAuth2 flow
- aka auth-code-flow
- uses front channel (solid lines) and back channel (dashed line)
- response type code
- client-secret is usually not needed in this scenario
- when there is no back-channel involved
- uses the front channel (solid lines) exclusively
- browser to server: e.g. SPA using JS which talks to the server
- response type resp. grant_type: token
- ensure the access_token cannot be leaked from the apps local storage
- refresh tokens are not given to a client with this flow
- is a mix of implicit flow and authorization code flow
- after a client got an access_token through the implicit flow it requests an authorization_code
- with this authorization_code it can do the token-exchange to obtain a refresh_token
-
back channel only
-
machine to machine communication
-
service to service communication
-
Request is made to the Auth-Service with the following information:
- grant_type is set to client_credentials
- client-id identifies the requesting party
- client-secret authorizes the requesting party
- scope contains the requested permissions
-
access_token is provided by the Auth-Service with the response
-
(id_token can also be part of the response when the server is able to talk OIDC)
-
SEE VIDEO https://www.javainuse.com/spring/springboot-oauth2-client-grant !!!
- back channel only
- (need to find out more information)
- extension to OAuth2.0
- ID token
/userinfoendpoint to get user information in a standardized way
- scope contains openid
- auth_code is used to exchange with an access_token and id_token
- id-token is a Json Web Token and can be used to provide a small subset of user information
/userinfoendpoint is used to get more user information
| Identity use cases | |
|---|---|
| Simple login (Open ID Connect) | Authentication |
| Single sign-on across sites (OpenID Connect) | Authentication |
| Mobile app login (Open ID Connect) | Authentication |
| Delegated authorization (OAuth2.0) | Authorization |
| Granting access to APIs (OAuth2.0) | Authorization |
| Getting access to user data in other systems (OAuth2.0) | Authorization |
| Logging the user in (Open ID Connect) | Authentication |
| Making your accounts available in other systems (Open ID Connect) | Authentication |
| Grant type | Scenario |
|---|---|
| Authorization | web application with server backend, native mobile app |
| Implicit | SPA (Javascript app) with API backend |
| Client Credentials | Microservices and APIs - access happens not on behalf of a user |
| Refresh Token | All scenarios where an access token can expire |
| Password | when a clients exchanges username and password for an access_token |
| Resource Owner Password | aka Password flow |
The password grant type is highly discouraged!
Destructures an access_token. Only trusted clients are allowed to issue requests against this endpoint. Therefor they need to authenticate.
Read documentation here to get an idea about security considerations and token phishing.
Exchange refresh token for access token by providing:
- refresh token
- client-id
- client-secret
- grant_type: refresh_token
Response is a new access token plus (optionally) an new refresh token.
If you do not get back a new refresh token, then it means your existing refresh token will continue to work when the new access token expires.
When refreshing fails the user must be prompted to relogin!
Note:
- access_token s have a short lifetime
- refresh_token s have long lifetime
- the combination maximized security and flexibility
- some services issue refresh_tokens which never expire
When your service issues a new access token in response to a refresh token grant, it is possible for your service to issue a new refresh token simultaneously, and expire the previous one. This means refresh tokens rotate out frequently, which may be desirable for your application. If this is the case, ensure developers know this will happen so they don’t mistakenly assume the first refresh token they obtain will continue to work indefinitely.
- scopes
- proof code for code exchange (PKCE)