leastprivilege
commented
7 years ago This seems to be a general question about IdentityServer - not a bug report or an issue.
Please use StackOverflow for that. This has the advantage that questions and answers can be easily found by search engines, and that there are more people answering questions than just us.
For IdentityServer3 https://stackoverflow.com/questions/tagged/?tagnames=identityserver3&sort=newest
For IdentityServer4 https://stackoverflow.com/questions/tagged/?tagnames=identityserver4&sort=newest
For commercial support options - visit https://identityserver.io
jgiganti
I have a web site using an out of the box Identity Service/OIDC username/password authentication request to lock down the pages at the web site.
I now need to be able to have a customer tell us which user was authenticated on their platform and map that into a user/identity on our platform and pass that information to the existing web site without having to prompt for a username/password.
I am currently using RequestCustomGrant to generate an access_token and I am able to map that data to a user/identity in our system and generate a valid access_token.
I then attempted to craft a URL with a hash fragment similar to https://xxxx/#access_token=eyJ0e.....&token_type=Bearer&expires_in=3600&scope=ps-api
The problem that I am running into is the oidc client seems to want both an access_token and an id_token along with some state information. If I also craft an id_token I get an error
Is it worth investigating the oidc-client and seeing if UserManager can take just an access token and then validate that, call back to the userinfo_endpoint to craft an id_token and persist that in the user store.
I am wondering if custom grants are the wrong approach and what the preferred approach is to handle a situation where the original authentication mechanism is using some custom approach and we would like to validate that request and generate a new token that can be used by our web applications and API which all expect JWT tokens.