MVC OWIN client + access token

[JamesReate]

On the MVC OWIN sample client example, I was trying to get the access token back somehow through the Microsoft OpenIdConnect plugin. I tried altering the Response_Type to include 'token' as well as doing a full scope but that didn't work. Besides, I'm not clear if this is even possible or how the access token would be returned so I can store it for the web api calls.

Awesome work on Identity server v3 and identity manager btw!

[leastprivilege]

Right now we don't support token response type for form_post response mode. I will change that soon.

[leastprivilege]

actually here is the PR - i will merge it in the next days

#56

[JamesReate]

I merged in your PR and now I can specify Response_Type = "id_token token", and it works.
Now my questions is, on my client app how do I pull the access token? I see that the POST request is made to my client app containing the Token but I have no way of intercepting it b/c the Microsoft OWIN OpenIDConnect plugin takes control of post requests on the "Redirect_Uri".
I guess may be more of a question for Vittorio Bertocci from MS Identity team.

Update - Instead of using the OpenIdConnect middleware, I just manually implemented the MVC form post example (per your sample clients) and this way was able to get the access token. Now the issue is that web api doesn't like the authentication bearer token and returns unauthorized. I'm guessing there is some extra glue needed to "register" the access token with the Client so it can be accepted.

[leastprivilege]

I asked myself the same question - i am pretty sure that in one of the notifications on the MW you would be able to intercept the token. I need to go through the source code in the next days.

[vibronet]

you can have the incoming token show up in the ClaimsPrincipal by setting SaveSignInToken = true in the TokenValidationParameter

[leastprivilege]

Is that the access token or the identity token?

[vibronet]

in OIDC, the id_token. Right now we support only id_token and id_token+code, hence the access token always comes out from your own code (e.g. by redeeming the code, etc)

[leastprivilege]

Well - technically - id_token token works fine. I was just wondering how to get ahold of the access token from the form post. There should be a notification that allows that.

[leastprivilege]

I really think that hybrid flow + form_post wasn't the best choice for the OIDC MW - it is not very well supported by non-WAAD ;)

[vibronet]

There is no access token in the forms post in the response_types we support, hence the OM does not contemplate anything for it. Once it will be folded in, we will need to expose it somehow... but for the time being it's out of scope :-)

[leastprivilege]

Well- what does supported mean ;)

I can set the Response_Type = "id_token token" and the MW does not complain..and the token will be the resulting post. So a generic notification that has access to the post body would be useful.

[vibronet]

good point, we should probably complain for the response_types we don't support to set the right expectations

[leastprivilege]

I think you shouldn't ;)

[leastprivilege]

Couldn't you simply provide access to the post body in the notification that creates the ClaimsPrincipal - there might be more stuff on the post body - but token being the most obvious

[vibronet]

Wouldn't you already have access to it in the MessageReceived notification? In any case, we need to be careful about setting expectations on what is a supported scenario for a given version. Hitting the right balance between "basic" users and sophisticated users requires us to be careful about it. Thanks for the feedback, this is definitely one area we have to think through more.

[leastprivilege]

I don't know - I haven't tried it. I am just saying that hybrid flow + form_post is quite esoteric and mainly mirrors the WAAD feature set. So make the MW useful it should do more than that.

[leastprivilege]

So if it is possibe in MessageReveived then you shouldn't restrict the response types. That would make the MW less compatible.

[JamesReate]

I agree that unsupported Response_Types should be allowed because it helps make the MiddleWare more compatible.
I think the Notificacions => MessageReceived might do the trick to intercept the POST that contains the access token. I've been playing around with it but I'm lost trying to implement it. If you could point to an example that would be great.

[leastprivilege]

I will try to add it to the OWIN sample in the next days

[JamesReate]

Fun stuff, that's awesome. I must shamefully admit that I've spent very little time learning functional programming in c#. I'll go ahead and close this post since I saw you created a new "todo" issue for this.

[leastprivilege]

I leave it open for now.

[leastprivilege]

OK - I added a sample - was easier than I thought ;)

https://github.com/thinktecture/Thinktecture.IdentityServer.v3/blob/master/samples/Clients/MVC%20OWIN%20Client/Startup.cs

@vibronet Please You have the right extensibility points, and the protocol message supports reading the token from the form - so please don't restrict the response type. thanks!

[JamesReate]

¿are you bragging? haha.. yeah looks pretty simple, i didn't know about that OwinContext.Set seems like a nice way to store values. Thanks for your help

[leastprivilege]

@vibronet makes sense?

[vibronet]

Yep, although I would probably not put the access token in a claim (the app might acquire other access tokens in its lifetime, which would have to be stored in a different place; the access token might get refreshed, and updating the claimsprincipal for that would be awkward; and so on)

[leastprivilege]

true. It's a sample.

[leastprivilege]

The "sense" part was more the - "this scenario is possible with the extensibility, please don't artificially restrict the response types" ;)