MVC OWIN client + access token about identityserver3 HOT 27 CLOSED

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

from identityserver3.

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

#56

from identityserver3.

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.

from identityserver3.

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.

from identityserver3.

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

from identityserver3.

Is that the access token or the identity token?

from identityserver3.

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)

from identityserver3.

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.

from identityserver3.

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

from identityserver3.

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

from identityserver3.

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.

from identityserver3.

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

from identityserver3.

I think you shouldn't ;)

from identityserver3.

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

from identityserver3.

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.

from identityserver3.

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.

from identityserver3.

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

from identityserver3.

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.

from identityserver3.

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

from identityserver3.

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.

from identityserver3.

I leave it open for now.

from identityserver3.

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!

from identityserver3.

¿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

from identityserver3.

@vibronet makes sense?

from identityserver3.

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)

from identityserver3.

true. It's a sample.

from identityserver3.

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

from identityserver3.