Client Credentials from within UserService on IdentityServer3

Question

I need to connect to an external API to validate user credentials and get claims for user from within my custom UserService in IdSrvr, but using Client Credentials as if IdentityServer were a client to connect to another service.

What should be the approach?

First thing to come to my mind was to just make an HttpClient instance within UserService to connect to IdentityServer itself and make the request... But I don't know if there's a better/cleaner way.

score 2 · Accepted Answer · answered Oct 25 '16 at 11:17

The OwinEnviroment extensionmethods let you issue tokens.

    public MyCustomUserService(OwinEnvironmentService owin)
    {
        _owin = owin;
    }

    public async Task AuthenticateLocalAsync(LocalAuthenticationContext context)
    {

        var token = await _owin.Environment.IssueClientToken(
            clientId: "Banana", 
            scope: "resource1", 
            lifetime: 3600);

       // call protected API with token
    }

Link to GitHub issue with same question

score 1 · Answer 2 · edited Oct 07 '21 at 11:10

1

There is a grant for this called the ResourceOwner Grant. Please read the spec accordingly.

The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged
application)

Most people would highly recommend that you do not use this grant as its an antipattern that requires the application to pass out user credentials which goes against the whole idea of OIDC. This grant is mostly here and used for legacy purposes.

edited Oct 07 '21 at 11:10

Community

1
1

answered Oct 21 '16 at 10:28

Lutando

4,909
23
42

Maybe I didn't explain myself good enough: I have a service to authenticate users for my organization and is basically a RESTful API. Now, from within the UserService of IdentityServer I need to call it to validate a user in IdSrvr during AuthenticateLocalAsync. Now, I need IdSrvr to issue to itself a token to send in the call to the authentication API, and _that_ is the part I'm trying to figure out as to what should be the best/cleaner. Resource Owner Credentials grant is supossed to be used when a user is logging into an application, but this is between services (IdSrvr to auth api) – CesarD Oct 21 '16 at 12:11
2

This kind of reminds me of this post in IDS4. To be honest I don't know weather something like this should be done. http://stackoverflow.com/questions/39981755/is-there-a-way-to-generate-an-access-token-from-within-identity-server-without-u Sounds like your users are accessible in another web api, but this very application is a relying party to the identity provider that requires the user information. basically you need a valid token from within the UserService. To be honest I wouldnt be so sure if this is clean but you gotta do what you gotta do. I think your solution would be fine. – Lutando Oct 21 '16 at 15:31
Yes, it's pretty much like the question you posted and the way you explained. And yeah, it's kind of twisted, but that auth api is there because it has to grab users from an AD and also from another personnel system and validate the user as a whole from both parts... Only then the user credentials are correctly validated and claims returned along with the validation result (if ok)... And it doesn't make much sense to bring all that logic inside IdSrvr too. I'll leave question open for any further feedback. Thanks for yours. – CesarD Oct 21 '16 at 19:45
1

@Lutando , can you back up your claims of resource owner flow being around just for legacy purposes? Do you have link? Also, how's it an anti-pattern? There are different use cases for each flow - not sure that makes one "better" than the other. CesarD . See answer above for how to generate tokens without creating a sep RP for idsrv itself. – John Korsnes Oct 25 '16 at 12:03
1

Absolutely @John. In essence the whole point of delegating sign on to an identity provider is to also limit the submission of credentials to the identity provider. The resource owner grant goes completely against this pattern, since credentials need to be passed through the client to the identity provider, compare this with the other flows where your credentials are passed only to the identity provider. More points as to why you should be careful about this flow can be found here - https://tools.ietf.org/html/rfc6749#section-10.7 – Lutando Oct 25 '16 at 13:31
Yeah, sure - but there are (and still will be) platforms were you have no browser present to do a redirect or delegate the input of credentials. AppleTV for instance. – John Korsnes Oct 25 '16 at 14:07
1

true that, remember, the spec does not say do not use it. It basically says use it with caution and if you must use it, do realize the risks. These user interaction flows were not designed without the browser context in mind. Which is why many platforms allow you to jump out of the app context and into a browser context to do SSO. It's a shame that Apple TV doesn't do this :P but year Apple TV's limitations justify the use of RO grant on that platform. – Lutando Oct 25 '16 at 14:47
Thx for the link, btw :) – John Korsnes Oct 25 '16 at 15:18
As I saw it, RO flow would only be useful for a mobile app trusted by the service. Such case would be Facebook or Twitter mobile apps, where there wouldn't be any reason to redirect user to somewhere else. Different thing is when you have a third party app that uses FB or TW accounts and because of that they need to redirect user to FB or TW portal pages to allow signin. Nice discussion though. Thanks :) – CesarD Oct 26 '16 at 01:15

Client Credentials from within UserService on IdentityServer3

2 Answers2