You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.
I've a question regarding some parts of the code and implicit flow, and about whose responsibility it is to handle them, and in case it is not the responsibility of the Identity Server, which I suspect it is not, if the regular OpenIDConnect Owin Middleware handles it.
Ok, I'm using the IdentityServer v3, and was looking at the code flow (this should apply to the implicit flow as well) and saw two use cases for starting the OpenIDConnect authorize request.
First, when this is handled by the OpenIDConnect Owin Middleware (using app.UseOpenIdConnectAuthentication), the request is made to the configured authority using the state and nonce generated by said middleware. But, from my observations, on the redirect back to the client, that same state and nonce are not validated. (at least I managed to make a post changing the initially sent state, or even removed the state altogether)
The second way of making the redirect to the IdentityServer authorize endpoint, is by manualing instantiating an OAuth2Client and setting the state/nonce manually. In this case, I would expect that the client would have to implement the validating of these fields.
Would it be wrong to expect the same validation to happen when the redirect is made by .NET framework-implemented Owin middleware.
Thanks, and any input would help.
EDIT: Also, just a small question regarding scopes in the OAuth2 flows. Do scopes have any purpose when you're talking about a fully trusted app that doesn't even require consent from the user? Do scopes have any other purpose, other than being shown to the user so he can select which permissions he wants to give to the client he is using? Thanks again.
Best regards
The text was updated successfully, but these errors were encountered:
As for what the Katana middleware does, you'd have to confirm in the source (or ask Microsoft). I looked quickly and it doesn't seem that the returned state is being correlated to the response, but I might be missing something. The nonce is being validated, though.
Hello,
I've a question regarding some parts of the code and implicit flow, and about whose responsibility it is to handle them, and in case it is not the responsibility of the Identity Server, which I suspect it is not, if the regular OpenIDConnect Owin Middleware handles it.
Ok, I'm using the IdentityServer v3, and was looking at the code flow (this should apply to the implicit flow as well) and saw two use cases for starting the OpenIDConnect authorize request.
First, when this is handled by the OpenIDConnect Owin Middleware (using app.UseOpenIdConnectAuthentication), the request is made to the configured authority using the state and nonce generated by said middleware. But, from my observations, on the redirect back to the client, that same state and nonce are not validated. (at least I managed to make a post changing the initially sent state, or even removed the state altogether)
The second way of making the redirect to the IdentityServer authorize endpoint, is by manualing instantiating an OAuth2Client and setting the state/nonce manually. In this case, I would expect that the client would have to implement the validating of these fields.
Would it be wrong to expect the same validation to happen when the redirect is made by .NET framework-implemented Owin middleware.
Thanks, and any input would help.
EDIT: Also, just a small question regarding scopes in the OAuth2 flows. Do scopes have any purpose when you're talking about a fully trusted app that doesn't even require consent from the user? Do scopes have any other purpose, other than being shown to the user so he can select which permissions he wants to give to the client he is using? Thanks again.
Best regards
The text was updated successfully, but these errors were encountered: