Not getting Claims back in sample about identityserver3.samples HOT 23 CLOSED

The OIDC spec basically states that the main thing in the id_token is the subject and all other claims are supposed to be available at the user profile endpoint (accessed with the access_token). Now, it also states that it's possible to put more claims in the id_token, but that's an implementation choice and/or detail. In IdSvr we have a flag on the ScopeClaim to indicate if it should always be included in the token.

The best complete sample (as of right now) that shows the additional calls to the user profile endpoint is the WPF client on the dev branch.

from identityserver3.samples.

Having the same issue using the membership reboot extensions. Pretty sure the method that handles building the claims up from the db also accepts a parameter listing the claims requested by the client. If this is empty then all claims are returned. However... During my testing its never empty and always has just the 'sub' claim by default. Thus excluding the other claims.

Sounds like the same issue.

from identityserver3.samples.

What is the response_type in the authorize request? You get back all the claims in the id_token only if it's just "id_token", otherwise those claims are available at the user profile endpoint. You can also get the claims by marking them "always include in id token".

from identityserver3.samples.

The response type in my case has been : token id_token
and the scope in my case has been: openid profile read write email

Which as I understand it returns an encoded OpenId identity token and an OAUTH authorization token with the encoded claims.

Using the sample js application this represents the 'Login with Profile and Access Token' use case.

I'm guessing now that this is expected that the access token should only contain these 'standard' claims and that the expected procedure is another request is made to the userinfo endpoint with the auth token sent in the headers.

So my workflow is now :

• the JS client using the above implicit flow to authenticate with IdSvr3 now making a http request to the API server with the auth token in the header.
• the server API would perform another request to the IdSvr3.userinfo endpoint to retrieve the full claims for the user and set these in the ClaimsPrinciple.

Is this workflow covered in one of the samples as it represents the missing piece of the puzzle for me?

Thanks in advance.

from identityserver3.samples.

Thanks Brock that does make sense... however I guess I'm still confused by the following:

My understanding is It's the access_token not the id_token that will be used in the HTTP header on subsequent calls by the client JS application to the Resource Server (API).

If that's the case I would want to have some common claims included in that access token. User display name and email for example so when the resource server does some operation I at least have that minimum information regarding the end-user without having to call the userinfo endpoint.

So is it possible using the OIDC implicit flow to tell IdSvr to add these additional claims into the access token?

from identityserver3.samples.

Thanks Brock and Galen
Will check out the WPF app and go from there

Rhys

from identityserver3.samples.

Looks like this blog post summarizes what issues I am hitting : http://www.appetere.com/Blogs/SteveM/August-2014/Getting-started-with-OpenID-Connect

Looks like a mismatch between IDSrv3 and the M$ owin middleware

from identityserver3.samples.

I may be on the wrong track here (and sorry for being annoying) but i dont seem to be getting a access_token returned.
ResponseType = "id_token token"
which means I cant hit the user endpoint to get the other claims

Sample response here :

POST http://localhost:51207/ HTTP/1.1
Host: localhost:51207
Connection: keep-alive
Content-Length: 1943
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:3344
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:3344/core/connect/authorize?client_id=implicitclient&redirect_uri=http%3A%2F%2Flocalhost%3A51207%2F&response_mode=form_post&response_type=id_token%20token&scope=openid%20email%20profile&state=OpenIdConnect.AuthenticationProperties%3DSSnkooKW3Qgvz-TMs0PlsqiydVT2xulAR7qWbUOjnQd9rD2fgSb30LDv9YK0jOlxzLCUjeqht2HFuqQvKRgr91Nn4QyBEC7aany8F0xDZ2Kq6ynA_2fT-0iPSvqkiJdFtmKWZwYSor_eWtrRaznwS6cJxClKzOXPH9mqpqrLbA0Cjkviasj4dcJPZm8hrVCTXXwdAmqj1-bkDNf1kYTRKA&nonce=635472273783219349.NTVkMWQ0YzktNGE2Zi00MmVhLWE3MjEtMDFiMzAxYTJiZmI4MTQ2OTZkNDUtNWI1My00NjlkLThmZTctZDU2NzJjNzI1Nzgy
Accept-Encoding: gzip,deflate
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: OpenIdConnect.nonce.OpenIdConnect=Rjg5dEVTNllVcThJQXY1a28yd2prQ04tUnY0RGR3eHE0blRmLTlKVURiV0VUUnBZcGxhc3VmNklUMEpRS0xGU1FjVmR2MkQtYVg4YTEzVTJIampQYmFPZUk1ZEdJeXN4ODVyMVJCMXVMT21SWTlGdFJMWUYwQ2ItWGtBOEdxa1lJdWZ0UEwyRENGc3RlQXlxLW9Md1dDVUNwYnlLQ2dfQUVGLWFGRTFCdFRWOGZoNkNHUWZtVUR4dTlXM3c1NXpyM0xIMGh5MHIzNGZ5cXBTLWlxbDhTSGlfTFY2Y0I4MV9GOE10MnlHM2JFdw%3D%3D; idsrv=AQAAANCMnd8BFdERjHoAwE_Cl-sBAAAAeXY61rX1YUeZOHgVwwifngAAAAACAAAAAAADZgAAwAAAABAAAAA6jS2WRgQn600JrQUPJzBoAAAAAASAAACgAAAAEAAAABUqB9VeLUTwKu_Hd3HAE9TIAAAAJXxlwRYTSPOefP8-EiRMi6C98je6mEIRxEpu9Ot6LaSSKn9ehWxngHE0z6oW-OsUJGywgwcHA7y75UHjDfE4I5AJ-aE-96k7NIMA5kYDjidGI9g4Q9c9o3gb-sQJKeVOmdlRPG6UkWb5f6FjmrmEAVMIOXsuS5oNw1CbIP8-xYPcWHB4JmLkm6lV9-IjHdsem6VtXCLHTn6Uz7fa1GI52U_rBp6getmvDmABQnWAclbxuuP9pqJy0QjGBi-UkIQz3pIVHeCHOsYUAAAApaxMeqF96ilg-lQVDvBk6eMDc4o

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSJ9.eyJub25jZSI6IjYzNTQ3MjI3Mzc4MzIxOTM0OS5OVFZrTVdRMFl6a3ROR0UyWmkwME1tVmhMV0UzTWpFdE1ERmlNekF4WVRKaVptSTRNVFEyT1Raa05EVXROV0kxTXkwME5qbGtMVGhtWlRjdFpEVTJOekpqTnpJMU56Z3kiLCJpYXQiOjE0MTE2MzA1ODUsImF0X2hhc2giOiJUdmY5RVl6aEJJSUhMVnJ1NWt3T2J3Iiwic3ViIjoiYWxpY2UiLCJhbXIiOiJwYXNzd29yZCIsImF1dGhfdGltZSI6MTQxMTYzMDU4NSwiaWRwIjoiaWRzcnYiLCJuYW1lIjoiYWxpY2UiLCJpc3MiOiJodHRwczovL2lkc3J2My5jb20iLCJhdWQiOiJpbXBsaWNpdGNsaWVudCIsImV4cCI6MTQxMTYzNDE4NSwibmJmIjoxNDExNjMwNTg1fQ.K_ho72NL06HMHOyPNYNl2cF5EGGQwnrQQQnLAn5rC4QIdWR4UJxXovIPg32WSr4GwEaRbDzQq70VbdcbXSD3ZNHhQSnpgVkb3aVK8sUg8hR0gQm7FnqAYE4qgsX1Bv2TzXDd39jG-x03R7dPqJotNv_6gMMQx7EEYhhQvWf2b9OJ6WHkKtZrItBL0tlsbM7wnYCm8OxG5VfMbu6dpITyHeXvtUkttHX3iiNCBqn5Qes-1WP6Aizvz6K3xyk-F_Nxbg0PjnxmBzPs37VIFRP_r6f9mxeHzbcuSA3Bo61ra-z4mUUbHlAjxUxsoQeABca_pHq4FXFtGuq5oyvAHRk2yg&token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImEzck1VZ01Gdjl0UGNsTGE2eUYzekFrZnF1RSJ9.eyJjbGllbnRfaWQiOiJpbXBsaWNpdGNsaWVudCIsInNjb3BlIjpbIm9wZW5pZCIsImVtYWlsIiwicHJvZmlsZSJdLCJzdWIiOiJhbGljZSIsImFtciI6InBhc3N3b3JkIiwiYXV0aF90aW1lIjoxNDExNjMwNTg1LCJpZHAiOiJpZHNydiIsIm5hbWUiOiJhbGljZSIsImlzcyI6Imh0dHBzOi8vaWRzcnYzLmNvbSIsImF1ZCI6Imh0dHBzOi8vaWRzcnYzLmNvbS9yZXNvdXJjZXMiLCJleHAiOjE0MTE2MzQxODUsIm5iZiI6MTQxMTYzMDU4NX0.fh_jyoyLQpu3LcbHb18KUXYZwux-zEeUXChVjsmP3BAoDz_GIVl92PkJNcMdRcLztuUjQuj0dqC__sfxV7d_kMRE7CtqysN4sl3Ex-RPZEJ6j6JqcMUASJXhjzaENvY2I4VA4VuTmv2DfzbwyOGT5tfjo4L8TQtIjRV7n97JuW6LhBs8A10A2tLUp6TqCIB_1Y3PthY96yGl_waq1eff_Lah8D2ray6n1v6EyO4NSSsUItR5SRUujMF7TvB_Dfpcr5MZxUXLbnta7dJONea-R_Ne_OJWYdzHKiUJ2p-rF9esN3J8RpoThZO8AOmuW_bdioAcDz99q8Rq_AIqYtu-_g&expires_in=3600&state=OpenIdConnect.AuthenticationProperties%3DSSnkooKW3Qgvz-TMs0PlsqiydVT2xulAR7qWbUOjnQd9rD2fgSb30LDv9YK0jOlxzLCUjeqht2HFuqQvKRgr91Nn4QyBEC7aany8F0xDZ2Kq6ynA_2fT-0iPSvqkiJdFtmKWZwYSor_eWtrRaznwS6cJxClKzOXPH9mqpqrLbA0Cjkviasj4dcJPZm8hrVCTXXwdAmqj1-bkDNf1kYTRKA

from identityserver3.samples.

@galenp we just released beta1-2 today (dev branch merged to master) and now you can indicate what claims should always be in the access token.

from identityserver3.samples.

@RhysC use the access token to hit the user profile endpoint (not the id_token). The id_token is meant just fro the client app to validate and consume.

from identityserver3.samples.

@brockallen thanks for the update, ive updated all the packages and samples. can you direct me to where you configure what claims should go into the access token?

from identityserver3.samples.

Sorry @brockallen : how do i get the access token? My understanding was that is was to be sent back on the auth response but as the example i posted above there is no access token in the reponse

http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthResponse

from identityserver3.samples.

@RhysC I'm getting Access tokens sent back fine running the samples.... what are you doing different?

If you point the JavaScript client sample to your IdSvr instance whats the result?

from identityserver3.samples.

@galenp ok coolm so i must be doing something wrong - I am running the MVC Owin sample - will try the JS one today

from identityserver3.samples.

@galenp on the scope, there's a Claims property on the Scope class. When the Type is ScopeType.Resource then the claim is always included in the token. When the Type is ScopeType.Identity then the claim is available at the user info endpoint, and can optionally be included in the token via the alwaysInclude propery on the ScopeClaim.

HTH

from identityserver3.samples.

Any update?

from identityserver3.samples.

Hi Brock

I've moved away from trying to solve this through a populated access token. Instead I get the userId from the subject part of the access token and queried membership reboot directly.

However I did try and test your proposal....

I created a new scope like so

 new Scope {
    Name = "userdata",
    DisplayName = "User Data",
    Type = ScopeType.Resource,
    Claims = new List<ScopeClaim>()
    {
        new ScopeClaim()
        {
            Name = ClaimTypes.Name,
        },
        new ScopeClaim()
        {
            Name = ClaimTypes.Email
        },
        new ScopeClaim()
        {
            Name = ClaimTypes.MobilePhone
        },
    } 
}

In clients I added this scope to the implicitclient client

 ScopeRestrictions = new List<string>
{ 
    Constants.StandardScopes.OpenId,
    Constants.StandardScopes.Profile,
    Constants.StandardScopes.Email,
    "read",
    "write",
    "userdata"
},

Now what I'm expecting to see when I use the JS client with the following configuration:
request('openid profile read write email userdata', 'id_token token')

Is my 3 claims populated in the access_token... instead my access token comes back as:

{
  "client_id": "implicitclient",
  "scope": [
    "openid",
    "profile",
    "read",
    "write",
    "email",
    "userdata"
  ],
  "sub": "fa62a30c-b38b-4800-873a-3d0ff3a6c3bc",
  "amr": "password",
  "auth_time": 1411955794,
  "idp": "idsrv",
  "iss": "https://id.propertycompass.com.au",
  "aud": "https://id.propertycompass.com.au/resources",
  "exp": 1411956380,
  "nbf": 1411956020
}

I must be missing something... but not sure what.

from identityserver3.samples.

@galenp you're on the least version of the dev branch?

from identityserver3.samples.

JS client in samples works as expected for me. I assume there is a mismatch between the M$ OWIN middleware and idsvr3 or i have mis-configured it (or have an incorrect expectation of what i should be getting)

from identityserver3.samples.

@brockallen also the MVC form post works as expected (i.e. i can return other claims) - i assume this is why the sample exists - is the OWIN client known to have issues?

from identityserver3.samples.

The form post sample is only requesting response type of "id_token" -- if that's all your authorization request is then you always get all the claims in the id_token. If you also request "code" or "token" then the claims are only in the id_token if they're marked on the ScopeClaim as alwaysInclude.

from identityserver3.samples.

thanks so much @brockallen - that makes a lot more sense.
Have gone back to the spec and the original samples - I had made cascading changes that lead me down the wrong path. Wiped the slate and have got the implicit and code flows working as expected. Thanks for your patience

Rhys

from identityserver3.samples.

No problem.

from identityserver3.samples.