1

I'm trying to understand OAuth 2:

As I understand it "access_token" and "authentication code" are really quite similar in that they represent the end-users will. The only difference is that the access_token can be used alone while the "authentication code" must be used with the app_secret (client_secret in rfc6749).

So in my mind it would clarify a lot, if they had similar names, like:

  • "full_token", "strong_token" or "super_token" for "access_token" as it can be used alone. It is really powerful, it must never be transferred over a non secure line. (But can be used to make requests directly from the browser)
  • "half_token", "weak_token" or "normal_token" for "authentication code" because it must be combined with the app_secret. It can be transferred over non secure lines, but as the app_secret never should be sent to the browser, it can never be used from there.

And as a consequence the corresponding grant type names would be called:

  • "full_token grant type" for "implicit grant type"
    • The term means that a full_token is generated directly and returned to the browser only, (since it is returned in the fragment of the redirect uri (the #-part of the uri) which is not included when the browser makes the redirect request (so it will never be exposed even if the request is to a non-secure uri)). The browser can then use it to extract data, or it can be transferred to the app server (if the app uses TLS)
  • "half_token grant type" for "authorization code grant type"
    • The term means that a half_token is generated, the app makes sure it comes to the app server (secure line not needed). At the app server it is sent along with the app_secret to extract data from the authorization server. (rfc6749 suggests that it should first be replaced with a full_token, but this shouldn't be necessary in my mind.)

Or are there other differences that I have missed?

Magnus Andersson
  • 13
  • 1
  • 3

2 Answers2

2

The authorization code is less like an access token than your summary implies. In particular, this is not accurate: "The only difference is that the access_token can be used alone while the "authentication code" must be used with the app_secret".

In OAuth 2.0 getting authorization and using authorization are very different, involving different actors with different kinds of information available to them. The authorization code is part of a handshaking process with the authorization server to get permission to access a protected resource. The resulting access token is then sent to the resource server (which does not need to know any client secrets or other credentials) to access the resource on behalf of a user.

So they are actually quite different.

Kevin Christopher Henry
  • 46,175
  • 7
  • 116
  • 102
0

your theory of

full_token, half_token, strong_token, super_token

exists because you misunderstood the Access_token and Authorization_code.

Authorization_code is a short lived token which is exchanged to get Access_token. Authorization server generate the Authorization_code and send back to the client to keep resource owner's credentials secret. client later exchange this Authorization_code for access token. Once you get the access_token the authorization code get expired and you can not issue another access_token for same Authorization_code.

To access your APIs you pass access_token in header with every request. you cant access your APIs with Authorization_code. That's why Authorization_code is not a half_token.

Similarly full_token, strong_token, super_token also doesn't make sense as we have only one access_token.

see Life cycle of Authorization code

Community
  • 1
  • 1
Suraj
  • 1,625
  • 1
  • 15
  • 33