OAuth 2.0 is a standard that apps can use to provide client applications with secure delegated access. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials. OIDC adds a signed ID token and a UserInfo endpoint.
romlly
One of the most complete blog post about OAuth2, nice job 
Tom
Amazing article!
Great job!
Aurélien Sylvan
The best article I’ve ever read about OAuth. Thank you !
TecbrÎc B’zile Tankeu
a real explanation of the thing.
Dennis Allard
Not very well written. Uses too much terminology before defining it. Perhaps OAuth2 is as complicated as this article makes it seem. Bummer.
Matt Raible
I’m sorry you don’t like it Dennis. Perhaps you’ll enjoy a presentation I did on the same topic a couple weeks ago. I recorded and uploaded it to YouTube. If that’s still not helpful, you should checkout our my colleague, Nate Barbettini’s OAuth 2.0 and OpenID Connect (in plain English). Most people love it.
Yash Ganthe
In the example, the Authorization Server (Google) is presenting a screen letting the user allow the application (SomeApp) access the resource (Gmail). Here Google and Gmail are from the same company. What is auth server is Okta? Is that a valid scenario? Can Okta present a screen asking for permission and the resource server Gmail give access based on the token given by Okta?
Yash Ganthe
The article says, once the token is received the resource server can serve data:
curl -H “Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA” <br> https://www.googleapis.com/…
What does the API server need to do to respect the request that carries the token?
Matt Raible
The auth server in Okta is in your developer account under API > Authorization Servers. A custom one is created for you named “default”, but you can create additional ones easily. As far as using Okta and Gmail together, yes it’s possible. If I go to Google Docs, or Gmail, and use my Okta email, it redirects me to Okta to login.
Matt Raible
The API server needs to be configured as a resource server that looks for an access token and denies access if one is not present. If you’re working in a certain language or framework, let me know and I can try to point you to samples and tutorials.
Yash Ganthe
Working in Java and NodeJS on the server side
Yash Ganthe
Can the authentication be done by one server and authorization by another? Do the authentication server and authorization server need to communicate?
Matt Raible
Authentication is not part of the OAuth 2.0 specification. The authorization server is something you set up at your IdP (e.g., Google, Facebook, or Okta). When you’re redirected to the authorization server, there’s likely an authentication process that happens, but how that happens is not defined as part of OAuth 2.0. To answer your question, I believe they’re on the same server most of the time.
Matt Raible
For Java and Spring Boot, there’s an Okta Spring Boot Starter that you can use for your resource server. We just published a post that shows how you can use this to set up a resource server. If you’re not using Spring Boot, take a look at Build a Java REST API with Java EE and OIDC. This shows you how to use a JWT Verifier filter, among other techniques. For Node, see our Node.js/Express.js Quickstart.
Yash Ganthe
I have created a diagram based on the blog post. https://uploads.disquscdn.c…
Please answer the questions marked in red. Thanks.
Micah
1) Why is there no client secret in this request?
The browser is making the request directly to the Authorization Server. It’s not safe to store a client secret in a browser app. Per the specification: https://tools.ietf.org/html…, only response_type and and client_id are required
2) How does the Auth Server know the user is authenticated
The step that’s pictured in the diagram above this represents “consent” ("WebApp wants to access XYZ ABC …). Consent occurs AFTER authentication. In the normal flow (as you can observe on Google, Facebook, Okta, etc.) is that you must authenticate first and then you’d see the consent dialog.
3) How does the Resource Server validate the access token with the Auth Server
Two options here. The OAuth specification does not dictate the format for tokens and as such, they are considered “opaque”. In this case, the Resource Server must make an introspect request of the Authorization Server to get back the information (like scopes and timeout) that the token represents. Introspect request and response is covered here: https://tools.ietf.org/html…. However, the second approach is now more prevalent and is used by Okta (and others). In this case, the access token is a JWT that has a signature computed using the RS-256 algorithm and a private key used by Okta. The resource server can use the corresponding public key (which it can obtain using the metadata from the well known endpoint, like: https://micah.okta.com/.wel… to validate the access token WITHOUT having to make the introspect request of the Authorization Server. This saves a lot of network traffic.
4) Does the Resource Server need to validate the access token every time
Yes. But, HOW the validation is done is dependent on the formatting of the token. If you’re using Okta, then, per the second part of #3 above, you would just validate the cryptographic signature using a library, like JJWT (https://github.com/jwtk/jjwt). If you’re using a provider that does not use JWT for access tokens, then you would need to make an introspect request.
Here’s a diagram to match (and update) yours:
Yash Ganthe
#2 > Who will be verifying that the Authentication has indeed happened and how? What happens if a browser tries to authorize without having authenticated?
Thanks a lot for the rest of the answers.
Micah
In the specific case, Okta handles the authentication. It’s (securely) stored the user credentials and performs the authentication prior to showing the consent form. But, it’s the same for other providers that support these types of flows. If you’re using Facebook, then Facebook does the authentication and presents the consent form.
If you’re not authenticated, you would see the hosted login form (both in the case of Okta and Facebook).
Antony Baasandorj
Can someone explain this:
Article said: Because these tokens can be short lived and scale out, they can’t be revoked.
But there is RFC 7009: token revocation (https://oauth.net/2/token-r…. Is the article talks about different token?