is a great starting point for teams beginning their journey to better security. Targeted by security training platforms. Often referenced in security questionnaires and contractors when vendors and buyers are investigating a product or service.
party app Twitter “Enter your Twitter username and password” 1 Requests data w/ creds 4 Responds w/ data for user 5 User sends credentials 2 3 Stores in plain-text :( Serves tweet timeline (or whatever) 6
App Authorisation Server Serves “sign in” link 1 User clicks “sign in” 2 Sends credentials 4 Sign in with Twitter Prompts user for credentials 3 Sends redirect with one-time code 6 5 Creds OK
“sign in” user experience Handles authentication May offer consent screen Redirects to app with one-time code Issues access token in exchange for one-time code
authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token.
authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token.
🚫 Resource Owner Password Credentials flow (response_type=password) gone 🚫 Bearer tokens are not allowed in URIs 🔒 Redirect URIs must be compared using exact string matches 🔒 Refresh tokens must either be sender-constrained or one-time use 🔒 When implementing the Authorisation Code Grant flow, the PCKE is now required
authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token. response_type=token response_type=password
sender- constrained one-time use Expire refresh tokens so they can’t be exchanged for a fresh access token Ensure the request to refresh came from the client that was issued the refresh token e.g. Demonstrating Proof of Possession DPoP header e.g. Mutual TLS
🚫 Resource Owner Password Credentials flow (response_type=password) gone 🚫 Bearer tokens are not allowed in URIs 🔒 Redirect URIs must be compared using exact string matches 🔒 Refresh tokens must either be sender-constrained or one-time use 🔒 When implementing the Authorisation Code Grant flow, the PCKE is now required