An introduction to OAuth 2

Editor's Notes

• #4: The power of OAuth is the notion of delegation. Although OAuth is often called an authorisation protocol, it is a delegation protocol. Generally, a subset of a user’s authorisation is delegated, but OAuth itself doesn’t carry or convey the authorisation. Instead, it provides a means by which a client can request that a user delegate some of their authority to it. The user can then approve this request, and the client can then act on it with the results of that approval. OAuth is used to grant authorisation. It enables you to authorise the web app A to access the information from the web app B without sharing your credentials. It was built with only authorisation in mind and does not include any authentication mechanism.
• #5: The token represents the access that’s been delegated to the client and it plays a central role in every part of OAuth 2.0.
• #11: The user’s authentication passes directly between the user (and their browser) and the authorisation server; it’s never seen by the client application. This essential aspect protects the user from having to share their credentials with the client application, the anti-pattern that OAuth was invented to combat.
• #13: The client can parse the HTTP parameter to get the authorisation code value when the request comes in, and it will use that code in the next step. The client will also check that the value of the state parameter matches the value that it sent in the previous step. State parameter is used to protect against CSRF attack. Cross-site request forgery (CSRF) is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g., provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie).  A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
• #15: The client performs an HTTP POST with its parameters as a form-encoded HTTP entity body, passing its client_id and client_secret as an HTTP Basic authorisation header. This HTTP request is made directly between the client and the authorisation server, without involving the browser or resource owner at all. This separation between different HTTP connections ensures that the client can authenticate itself directly without other components being able to see or manipulate the token request.
• #18: The response can also include a refresh token (used to get new access tokens without asking for authorisation again) as well as additional information about the access token, like a hint about the token’s scopes and expiration time. In Okta, using the authorisation_code grant type also returns an ID token if the openid scope is requested. ID token is a JWT. ID token must be validated before use. 
• #22: The client is generally the simplest component in an OAuth system, and its responsibilities are largely centered on obtaining tokens from the authorisation server and using tokens at the protected resource. The client doesn’t have to understand the token, nor should it ever need to inspect the token’s contents. Instead, the client uses the token as an opaque string.
• #29: Refresh tokens also give the client the ability to down-scope its access. If a client is granted scopes A, B, and C, but it knows that it needs only scope A to make a particular call, it can use the refresh token to request an access token for only scope A.