1

I'm currently studying OAuth 2.0 and OpenID Connect and I have a doubt regarding the Authorization Server and Access Tokens. The spec defines the Authorization Server as:

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

So as I understood, the client redirects the user to the Authorization Server, the user authenticates itself at the Authorization Server and the Authorization Server issues an access token to the client.

Now here comes a thing I couldn't understand until now. There are two possible ways to understand this and I'm trying to get the right one:

  1. The Authorization Server issues the access token containing the user's claims. The access token with the user's claims is sent with each request to the resource server and the resource server is able to read those claims and based on then allow or deny access to resources.

  2. The Authorization Server issues the access token already containing explicit instructions to allow or deny access to resources on the resource server. The resource server thus just reads this information to see if the user can do something or not.

The first option seems to be right way to understand the thing. In that case the Authorization Server will manage the user's claims and issues tokens containing just the claims (things like birthday, age, role and so on). This, in turns gives another responsibility to the resource server: deciding based on claims if a resource is available or not.

The second option is much more limited. Instead of just issuing claims the authorization server would need to issue authorization for each resource, and the token could get quite heavy and mananging this complexity seems to be hard.

So is my understanding correct? The Authorization is thus responsible for managing user claims and issuing token containing just the claims? On the other hand the resource server is responsible for allowing or not the access to resources based on claims?

user1620696
  • 10,825
  • 13
  • 60
  • 81

1 Answers1

4

An access token does NOT contain a user's claims, but an ID token does.

An authorization server is responsible for managing access tokens, but it does not necessarily have to manage users' claims. There should be a separate server that manages users' claims.

No. 2 sounds weird, because existence of an access token means "authorization has been granted."

OAuth 2.0 (RFC 6749) is a specification for authorization. OpenID Connect is a specification for authentication. Don't be confused.

Community
  • 1
  • 1
Takahiko Kawasaki
  • 18,118
  • 9
  • 62
  • 105
  • Thanks for the answer @TakahikoKawasaki. There's just one point I've missed. As I've learned, authorization to resources should be done based on business rules checking user's claims. If the access token doesn't contain user's claims, what it really contains? I mean, we have to ask the Authorization Server for each individual resource and the access token contains information to allow each one of them individually? – user1620696 Dec 19 '15 at 15:05
  • Checking based on claims and checking based on [scopes](https://tools.ietf.org/html/rfc6749#section-3.3) (permissions) are different things. The former is an access control based on roles (= attributes of a user). The latter is an access control based on access tokens (= permissions granted by a user). If you want to protect your Web APIs based on roles, you don't need access tokens. – Takahiko Kawasaki Dec 19 '15 at 15:27
  • In general, an access token is associated with information about "who (user) has granted what permissions (scopes) to whom (client application)", and it is NOT associated with user claims. [RFC 7662](https://tools.ietf.org/html/rfc7662) is a specification to get information about an access token. The specification shows what information is associated with an access token in general. – Takahiko Kawasaki Dec 19 '15 at 15:35
  • So when we use OAuth the authorization is not to the user but to the client application? So we should not use OAuth to authorize some user to access some resource, but only to authorize some client application to access a resource in the name of the user? – user1620696 Dec 19 '15 at 22:18
  • Your understanding is correct. Both are called "authorization". Note that you can use both access control mechanisms (role-based and token-based) at the same time. FYI: Good to read: [Resource-Based Access Control](https://stormpath.com/blog/new-rbac-resource-based-access-control/) (by Stormpath), [Understanding Permissions in Apache Shiro](http://shiro.apache.org/permissions.html) – Takahiko Kawasaki Dec 20 '15 at 05:33
  • OAuth in one sentence: *OAuth 2.0 is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.* (from Authlete [Overview](https://www.authlete.com/documents/overview)) – Takahiko Kawasaki Dec 20 '15 at 05:36