OIDC returns a signed JWT/id_token from the token endpoint that can contain all of that information (no extra round trips). Setting a id_token as a cookie is not unusual. I would not conflate the access token with session tokens.
John B. > On Aug 23, 2015, at 3:32 PM, Donghwan Kim <[email protected]> wrote: > > Hi folks, > > First off, I appreciate your answers. > > What I try to do with OAuth is to design a set of APIs which allow to write > application without server in a standard-compliant way and I chose OAuth for > the social web. Because the current API I work on uses a kind of Form-based > authentication (https://en.wikipedia.org/wiki/Form-based_authentication > <https://en.wikipedia.org/wiki/Form-based_authentication>), I started with > Resource Owner Password Credentials first to support other grant types > gracefully later. Here I faced the problem with authentication. (Now I > realized that I may have abused OAuth according to your answers) > > My thought is to use access_token as a session token containing values like > roles not just a reference on server's memory indicating such values > (traditional cookie). That means access_token should be a JSON Web Token > (JWT) which contains usename (to log who did an action), roles (ACL, to > determine this request has a proper permission), and so on. Then every server > (or microservice unit) accepting request doesn't need to have not only > session states in its memory (stateless), but also a dependency with auth > server because access_token included in Authorization request header as > bearer token contains all about authentication and authorization information. > Having said that, because token would be not valid over time if values > contained in the token might be changed e.g. role or due to OAuth's > expiration mechanism, removing dependency with auth server is unlikely to be > feasible practically IMO. (Then it would be better for access_token to be > reference rather than a set of values) > > As for the original question, as Bill pointed, it's okay to get user > information by username through other separate endpoint for that purpose > (like /userinfo from the context of OpenID Connect (OIDC)). Though, I wanted > to reduce round-trip by adding a custom property to token endpoint's response. > > Here's some questions: > > 1. Is it an abuse of OAuth to use access_token as a session token which is a > set of values not reference on server indicating values? or what if it is in > the form of reference? As far as I read https://tools.ietf.org/html/rfc6749 > <https://tools.ietf.org/html/rfc6749>, I didn't feel that access_token should > not be like that. On the contrary, if I introduce another standard for > authentication, API implementators should do more work and I didn't want to > do that. In this case, support for OIDC can be regarded as enhancement of API > like Google did https://developers.google.com/+/web/api/rest/openidconnect/ > <https://developers.google.com/+/web/api/rest/openidconnect/> > > If not or it doesn't sound that good, I'll take a look > https://tools.ietf.org/html/draft-ietf-oauth-introspection-11 > <https://tools.ietf.org/html/draft-ietf-oauth-introspection-11> and > http://openid.net/specs/openid-connect-core-1_0.html > <http://openid.net/specs/openid-connect-core-1_0.html> which you suggested. > (Though I'm not comfortable that OIDC is also regarded abuse of OAuth > according to http://security.stackexchange.com/a/44614 > <http://security.stackexchange.com/a/44614>) > > Thanks! > > -- Donghwan > > On Sat, Aug 22, 2015 at 1:42 AM, William Denniss <[email protected] > <mailto:[email protected]>> wrote: > As for your specific use-case though, as John said it's better to use OpenID > Connect which provides a solution for what you are trying to do already. > > That way you get an interoperable solution, and one that has been vetted by > security experts. There is even a free test suite > <http://openid.net/certification/testing/> for you to test your > implementation. > > On Fri, Aug 21, 2015 at 9:35 AM, John Bradley <[email protected] > <mailto:[email protected]>> wrote: > Requests to the token endpoint are URL form encoded not JSON in your example. > > The use of the password credentials grant was to allow migration from HTTP > basic, but it not recommended for privacy and security reasons. > > OpenID Connect is a better way to authenticate users. > > However assuming you have a closed system and don’t care about > interoperability between clients and the Token endpoint, you could just add > that parameter to your AS and the world will not end. > > If you want to have interoperable clients then you should register the new > element in the IANA registry Sec 11.2 of the spec. > > Parameter name: > The name requested (e.g., “username"). > > Parameter usage location: > token response. > > Change controller: > For Standards Track RFCs, state "IETF". For others, give the name > of the responsible party. Other details (e.g., postal address, > email address, home page URI) may also be included. > You need to have a specification to do that. > > I don’t see this as a good idea, but that is how you would do it. > > Regards > John B. > > >> On Aug 20, 2015, at 11:15 AM, Donghwan Kim <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> I would like to add a custom property representing the account who just >> authenticated to the access token response for the sake of convenience like >> login request's response. Then, an exchange of request and response will >> look like this: >> >> POST /tokens HTTP/1.1 >> Host: api.example.com <http://api.example.com/> >> Content-Type: application/json >> >> {"grant_type":"password","username":"${username}","password":"${password}"} >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> Pragma: no-cache >> >> { >> "access_token":"${JSON web token}", >> "token_type":"Bearer", >> "account": {"username":"donghwan", ...} >> } >> >> However http://tools.ietf.org/html/rfc6749#section-5.1 >> <http://tools.ietf.org/html/rfc6749#section-5.1> says that >> >> > The client MUST ignore unrecognized value names in the response. >> >> Does it mean that I shouldn't add such property, 'account'? Though, I saw >> Instagram API adds such custom property to access token response for the >> same purpose from https://instagram.com/developer/authentication/ >> <https://instagram.com/developer/authentication/> (Please find 'snoopdogg' >> to see that token response.) If it's not allowed or desirable, how should I >> add such information to the access token response? >> >> BTW, I have some questions on usage of JSON web token with OAuth. Can I post >> them here? If not, where should I do that? >> >> Thanks, >> >> -- Donghawn >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
