OAuth2 Server: passing extra data with access_token

[Konstantin Alexandroff]

We've got a very simple process (for now), we ask for user authorization but returning access_token is the end of the road, no resource server yet.

But, we'd like to provide some extra details like user identifier along with access_token. Is there a way to do so?

And if there is, what's the best way of getting this info? I guess it's encoded in access_token and I can use some code from resource server sample but perhaps there's an easier way in our case?

Thanks!

[Andrew Arnott]

Hi Konstantin,

I see nothing in the OAuth 2 spec forbidding embedding additional parameters in the access token response.  You should be able to achieve this with DotNetOpenAuth by calling AuthorizationServer.PrepareApproveAuthorizationRequest (instead of merely ApproveAuthorizationRequest).  The resulting value is a message with an ExtraData dictionary that you can throw extra parameters into.  Does that work for you?

Yes, the access_token has this information already encoded, but that information is encrypted expressly for the resource server, so if it's the client that wants the information, it's inaccessible unless it shares the decryption cert with the resource server or it's passed via ExtraData as I've described above.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/tGSdGs_OyskJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Konstantin Alexandroff]

Thanks! But how can I best get to it?

I can't even get to access_token as I can't cast response to AccessTokenSuccessResponse (it's internal), but maybe I don't have to? I'm guessing it'd be easier to get info directly from AuthorizationServer?

[Andrew Arnott]

I'm sorry if I was unclear.  You don't need to get to the access_token.  The result of PrepareApproveAuthorizationRequest has an ExtraData property on it that you can use like this:

AuthorizationServer as;

var response = as.PrepareApproveAuthorizationRequest(req, username, scopes, callback);

response.ExtraData["Username"] = username;

// Then EITHER of these, based on the web technology you're using:

as.Channel.Send(response);  // in Web Forms, OR

return as.Channel.PrepareResponse(response).AsActionResult(); // in MVC

Does that make sense?

On Wednesday, February 15, 2012, Konstantin Alexandroff wrote:

Thanks! But how can I best get to it?

I can't even get to access_token as I can't cast response to AccessTokenSuccessResponse (it's internal), but maybe I don't have to? I'm guessing it'd be easier to get info directly from AuthorizationServer?

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/odfyMcdKIAYJ.

To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Konstantin Alexandroff]

Wait a minute. You're talking about PrepareApproveAuthorizationRequest(), I haven't thought I can add extra data there too. Will this data be added as url params? If I can do that and if it doesn't violate the specification, it's definitely a solution although I can't say it's perfect.

I was thinking about adding more data to json, along with access_token, something like:

var response = this.authorizationServer.PrepareAccessTokenResponse(request);

// get username somehow

response.ExtraData["claimed_identifier"] = username;

return this.authorizationServer.Channel.PrepareResponse(response).AsActionResult();

But at this point (/Token called by Client server) username is hidden somewhere inside request or, more precisely, authorization token.

I can see, in sources of AuthorizationServer.PrepareApproveAuthorizationRequest() that there's a switch from authorizationRequest.ResponseType which can be EndUserAuthorizationResponseType.AccessToken which, I can only assume, redirects with access token instead of authorization token. But I definitely lack knowledge of this workflow, never seen it in use and not sure if it's a good way, I would prefer to go with more secure workflow as we'll need it later.

So, the question is still, can I somehow (easily) get user info at /token request processing? And, if not, is there an option for simplified process which will allow what I'm trying to do?

Thanks for your patience and answers! I guess I should examine the sources and spec more closely.

[Andrew Arnott]

Ah, ok I think I understand the disconnect here.  Let's just iron out some terminology for clarification.  In OAuth 2, there is no such thing as an "authorization token".  There are authorization codes, refresh tokens and access tokens.  

I now gather (with your last email) that you want to extract the username from the authorization code so that you can send it in plaintext to the client with the access token as part of the JSON text.  Sounds perfectly reasonable.  While it's not possible today, I've filed issue #77 so we can get it fixed in the next release.

Just to double-check: you want the client to know the username of the authorizing resource owner, as he/she is known by the authorization server, right?  The alternative might be to learn the username of the resource owner as they are known by the resource server (it could be a different account/username, potentially).  If this latter situation was the case you're after, then #77 doesn't cover it.  You could achieve the latter by having the client send the access token to the resource server on a URL that returns the username.  This is akin to what Facebook does during login to allow the client to learn the username, I think.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/sK377PMd7o0J.

[Konstantin Alexandroff]

You're absolutely right, that's what we want to do, to provide username (and possibly some other profile info) of user as it is known by the authorization server. Basically, we (like many others) use authorization protocol (oauth2) for authentication purposes, hence all the troubles.

At this point, we just added another method for returning this info (turned out it's super easy to create simple resource provider inside mvc app).

Thanks for your time answering all the questions and for such a great work! Will be waiting for new version.

[Andrew Arnott]

Hmmm... Why are you using oauth2 for authentication?  Why not use OpenID?  There are unresolved security concerns with using oauth(2) for authentication since it wasn't built for that -- it was built for authorization.  

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/aJQF3TDBLNwJ.

To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--

[John Bradley]

Facebook also returns the user ID in the signed_request token.  The documentation is somewhat lacking though.

OpenID Connect provides a standard way of adding identity information to OAuth 2 but supports multiple IdP and some other features that are not important to Facebook.

http://openid.net/connect/

If Andrew adds connect support, there will be a standard way to get the user_id form the Authorization endpoint in a trusted way.

Regards

John B.

[Konstantin Alexandroff]

Andrew,

authentication is what we need now but it's just a prototype of a much bigger system which will unite many company services (much like google), so oauth2 seemed like a natural choice, it can give us authentication and authorization means. As for the concerns, do you mean risks of not enforcing ssl or are there more fundamental flaws?

[John Bradley]

Some things to think about.  http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

Google is working on the openID Connect spec for there OAuth 2 authentication.   http://openid.net/connect.

There is a interop of the open source implementations going on now http://osis.idcommons.net/wiki/OC3_OpenID_Connect_Interop_3.

Doing your own is fine, but you may want to consider what eBay, Google, Microsoft and others are working on.

John B.

On 2012-02-16, at 4:18 PM, Konstantin Alexandroff wrote:

Andrew,

authentication is what we need now but it's just a prototype of a much bigger system which will unite many company services (much like google), so oauth2 seemed like a natural choice, it can give us authentication and authorization means. As for the concerns, do you mean risks of not enforcing ssl or are there more fundamental flaws?

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/qSRiZRyQ2fgJ.

[Konstantin Alexandroff]

John, thanks for the interesting read!

I'm definitely against inventing something new when there's a standard stable solution. Unfortunately, it seems these are far from being standard and we have to deal with what we have available. Even oauth2 is still a draft sadly, all of this may cost a lot of time and money.

[John Bradley]

Connect is approved as an implementers draft and there are already implementations.

Nothing stops you from following the pattern if not the detail.  It is better than starting from scratch.

It is also the cheapest work you will ever get out of me:)

John B.

On 2012-02-16, at 4:50 PM, Konstantin Alexandroff wrote:

John, thanks for the interesting read!

I'm definitely against inventing something new when there's a standard stable solution. Unfortunately, it seems these are far from being standard and we have to deal with what we have available. Even oauth2 is still a draft sadly, all of this may cost a lot of time and money.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/3nhAbWYImRMJ.

[Andrew Arnott]

If you want to use what's available today, then you should use OpenID with the OAuth 1.0 extension.  As you said, neither OAuth 2 nor OpenID Connect are final.

I do plan to add support for Connect in the coming months.

Sent from my Windows Phone

---

From: John Bradley
Sent: 2/16/2012 12:03 PM
To: dotnet...@googlegroups.com
Subject: Re: [dotnetopenauth] OAuth2 Server: passing extra data with access_token