How to get user-name in CreateAccessToken

[Fred]

Hi,

 

when I use ExchangeUserCredentialForToken on the client, to obtain a token, DNOA calls IAuthorizationServerHost.TryAuthorizeResourceOwnerCredentialGrant on the auth-server. I use this method, to find out, whether the username and the Password are correct and to return the "canonical" user-Name.

 

Exactly this user-Name is what I need within my implementation of IAuthorizationServerHost.CreateAccessToken, which is also called by DNOA after that. I need it, because, I want to set extra-data this user.

 

What is the supposed way, to have access to the user-Name from within this method?

 

Shell I set the CurrentPrincipal within TryAuthorizeResourceOwnerCredentialGrant  or shell I just put the user-name into a member-variable?

 

Wishes,

Fred

[Andrew Arnott]

On Fri, Jul 27, 2012 at 10:48 AM, Fred <manfred...@gmx.net> wrote:

Exactly this user-Name is what I need within my implementation of IAuthorizationServerHost.CreateAccessToken, which is also called by DNOA after that. I need it, because, I want to set extra-data this user.

Setting extra data in the access token will not be effective if you want the client to be able to read it.  

 

 

What is the supposed way, to have access to the user-Name from within this method?

I'm a little surprised in retrospect (although maybe there was a reason for it) to see that CreateAccessToken doesn't have access to the username here, but you're right.  Let's address that if you still want this after this reply.

 

Shell I set the CurrentPrincipal within TryAuthorizeResourceOwnerCredentialGrant  or shell I just put the user-name into a member-variable?

No, and no.  Setting CurrentPrincipal would fool your web app into believing the client was the user, which would circumvent all OAuth 2 scoping and open you up to security holes.  Setting it in a member variable would not work if you had even just two people authorizing concurrently.

Finally, it sounds like you're trying to misuse OAuth 2 as an authentication protocol.  OAuth 2 authorization servers should not be used to tell the client the username of the user.  If you want to authenticate the user please use OpenID.  

Alternatively, the not-recommmended way to do this with OAuth 2 (ala Facebook) is to return the username that authorized the access token from the resource server rather than directly from the authorization server with the access token response.  So after the client gets the access token, it calls some documented URL on the resource server to (for example) get JSON back with the username and the client_id that was issued the access token.  The client must also check that the response's client_id matches its own client_id (if you are in fact misusing the protocol for authentication) to avoid a very common security exploit when using OAuth 2 for authentication.

I hope this helps.

[Fred]

Hi Andrew,

thanks for your reply. The extra-data is for the ressource-server. For instance, the token could get the scope http://whatever/movies and the extra-data-entry: age=14. This could tell the ressource-server to just display a specific sub-set of the movies.

 

>> Alternatively, the not-recommmended way to do this with OAuth 2 (ala Facebook) is to return the

>> username that authorized the access token from the resource server [...]

 

Google uses this solution too and it seems, that this solution is pretty close to the current proposal of OpenId Connect.

Does that mean, that OpenId Connect shows, how to mis-use OAuth2 for Authorization the right way?

 

I would be very interested in your opinion towards this ...

 

Wishes,

Fred

 

[Andrew Arnott]

On Sat, Jul 28, 2012 at 10:41 AM, Fred <manfred...@gmx.net> wrote:

Hi Andrew,

thanks for your reply. The extra-data is for the ressource-server. For instance, the token could get the scope http://whatever/movies and the extra-data-entry: age=14. This could tell the ressource-server to just display a specific sub-set of the movies.

Perfect.  Then yes, setting ExtraData in the access token is the right way to go.  

 

 

>> Alternatively, the not-recommmended way to do this with OAuth 2 (ala Facebook) is to return the

>> username that authorized the access token from the resource server [...]

 

Google uses this solution too and it seems, that this solution is pretty close to the current proposal of OpenId Connect.

Does that mean, that OpenId Connect shows, how to mis-use OAuth2 for Authorization the right way?

Sort of ironic, but yes.  OpenID Connect builds on top of OAuth 2 in such a way as to maintain the security of using it for an authentication protocol.  

[Manfred Steyer]

Hi Andrew,

 

>> Perfect.  Then yes, setting ExtraData in the access token is the right way to go.  

 

thanks. But that leads to the original question – How to get access to the user-name within CreateAccessToken?

 

Wishes,

Fred

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
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 guess file a ticket for that one.

http://bit.ly/dnoawish
--
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

[Andrew Arnott]

Good call.  It looks like this ticket might have been meant to track it, but it was resolved another way. Please file another.

On Friday, October 19, 2012, lawst wrote:

I also require access to the username in the CreateAccessToken method however I can't find an open ticket - can someone please advise what the current status of this is?

thanks

.
To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

For more options, visit this group at

http://groups.google.com/group/dotnetopenid?hl=en.

--

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

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.

--
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/-/lqUV2XN_TOcJ.

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.

--

[lawst]

I see you beat me to it:

https://github.com/DotNetOpenAuth/DotNetOpenAuth/issues/219

thanks

[Andrew Arnott]

Yes, someone else was asking about it on Stackoverflow and I saw it wasn't there yet.

--
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

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

[steve]

For anyone using the resource owner password credentials grant with DNOA 4.1, if you pass the accessTokenRequestMessage parameter to the following method you can get the username in the CreateAccessTokenMethod:

string GetUserFromAccessTokenRequest(IAccessTokenRequest accessTokenRequest)
{
    if (accessTokenRequest is IAuthorizationDescription)
    {
        return ((IAuthorizationDescription)accessTokenRequest).User;
    }
    else if (accessTokenRequest is AccessTokenRequestBase)
    {
        // Use reflection to get username
        Type type = accessTokenRequest.GetType();
        foreach (var p in type.GetProperties(BindingFlags.NonPublic | BindingFlags.Instance))
        {
            if (typeof(IAuthorizationDescription).IsAssignableFrom(p.PropertyType))
                return ((IAuthorizationDescription)p.GetValue(accessTokenRequest)).User;
        }
    }

    // Error
    return null;
}

It may also work with other grant types however I've not tested it. This is obviously a workaround so use at your own risk!

Steve