Access Tokens as proof of user Authentication in projects of oauth2-vanilla and oauth2 at master branch

[mingqin1]

Hi: Dave
Those two projects ( oauth2-vanilla and oauth2) seem creating a new grant_type ( AuthorizationCodeGrant) and employing access_token as the proof of user authentication

I am expecting those two projects are implementing openid connection standard as user authentication. Or at least , tutorial could explain to readers the risks of using accss_token as the proof of user authentication has some pitfalls in user authentication.

See following captured traffic during usr login in from http://localhost:8080 .
The first is obtained from oauth2-vanilla project .

The second is from oauth2 project

Ming Qin

[dsyer]

I'm quite surprised to see that grant_type (it should be "authorization_code"). There may be a bug somewhere with the string literal, but it is the normal oauth2 auth code flow, as explained in the guide (e.g. it would work with external providers as well).

Openid is just a thin layer on top of the auth code flow (plus it isn't widely implemented, so the samples are more widely applicable as they are). Can you explain what the risks are that you refer to? Spring OAuth does permit the implementation of an Openid auth server, but it isn't autoconfigured and requires some customization, so it's probably not appropriate for this tutorial, unless we expand it.

[mingqin1]

Hi Dave:
One of the risks of using access_token as the proof of user authentication has some pitfalls in user authentication is opaque access token

Opaque access token itself could not be parsed for the usage of validating against authentication event process data being collected.

But, OpenID Connect’s ID token can be parsed to get aud claim which is the audience of the token. The parsed aud claim from ID totken itself would be helpful to tell whether authentication occurred for specific clientId.

In oauth2-vanilla example, for default user as “user” and clientId as “acm” whose access_token ( like 355d7bc2-50ce-4cec-b0aa-cd409bb89357) is opaque which is generated by UUID.radnomUUID ().toString by the DefaultTokeService.java.

The approach of getting authentication proof when accessing protected resource endpoint ( localhost:9000), which is http://localhost:9999/uaa/user using opaque access_token as a key of CurrentHashMap to get authentication event of information .

Unfortunately, whatever authentication event information (authorities, details, authenticated, userAuthentication, principle,credentials, clientOnly, oauth2request and name) fetched back from CurrentHashMap by key(access_token) is irrelevant to opaque access_token itself.

 Oauth2 example’s access_token  is not opaque anymore, including jti and client_id which can be substitutes of some claims of OpenID Connect’s ID token.

{
"exp": 1504281777,
"user_name": "user",
"authorities": [
"ROLE_USER",
"ROLE_ACTUATOR"
],
"jti": "16737006-ae04-4ca5-9a72-af8e94dc0703",
"client_id": "acme",
"scope": [
"openid"
]
}

2.Spring-Security-OAuth2 doesn't invent new grant_type as AuthorizationCodeGrant
Showing grant_type as AuthorizationCodeGrant was caused by string literal of the monitoring application I set up to record the network traffic, since AuthorizationCodeGrant was also displayed when I applied the same monitoring application to an OAuth2 Node.js implementation.

Conclusion: Hope to see the tutorial of Spring OAuth OpenId auth Server. Thanks
Ming Qin