How does openID Connect truly authenticate a user?

Question

From my understanding the difference from OAuth to OpenID Connect is that when the client hits /token endpoint of OAuth, OAuth responds with the following:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
   "access_token": "SlAV32hkKG",
   "token_type": "Bearer",
   "refresh_token": "8xLOxBtZp8",
   "expires_in": 3600,
   "id_token": "e134j23jk432j"
}

I was under the impression from reading documentation that the ID token contains an authentication type to denote if the user passed authorization by inputting a password. This would therefore verify the user did authenticate, not just authorize. I'm just not clear how the token is used to verify this.

It's my understanding the id_token isn't opaque to the client, so is there a standard way in which information is interpreted by the client?

Further, the documentation I found at http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html under 5. Definitions of Multiple-Valued Response Type Combinations shows an example request for id_token being made to /authorize. Shouldn't id_token be obtained at /token?

The amr claim (Authentication Methods References) is optional I believe - so you may not be able to get info of whether password used not. Either way I'm not sure what you mean about verify the user did authenticate, not just authorize. Whether password entered or not they were authenticated by the IdP. Nothing is being authorised — iandayman

Kavindu Dodanduwa Kavindu Dodanduwa · Accepted Answer · 2017-07-11T04:12:12

It's my understanding the id_token isn't opaque to the client

So this is where you need a clarification. Id token is a JWT (rfc7519) and it must be verified by the client.

Note that "client" here is the relying party. For example it's a web site. This client relies on the authorisation done at openid provider (authorisation server as described in rfc6749) and uses the id token in the response to authenticate the "end user".

Quoting from the documentation,

The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT)

Now, back to the question. How to read and understand a JWT and use it to authenticate a user. Specification for JWT is here - rfc7519. It contains basically three sections in following format,

H.C.S

H (header) - Contains type and algorithm and other meta information

C (JWT Claims) - Contains claims regarding authorised user

S (JWS Signature rfc7515) - A basically a MAC which is to verify header and claims

And each of these parts are base64url encoded. Note that JWS is signed by the token issuer.

Quoting from the documentation

ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14

What need to be validated in an id token, the specification mention what you need to do.

Hope this clarifies your doubt about JWT and how it's used to authenticate "end user"

Shouldn't id_token be obtained at /token?

It depends on the flow you use. For example the implicit flow allows you to obtain id token in the authorisation response.

p.s - To see the contents of a id token, you can use debugger functionality from https://jwt.io/

How does openID Connect truly authenticate a user?

1 Answers