CODEWITHSUNDEEP
oauth-2.0authorizationopenid-connect
Fernando Espinosa
Fernando Espinosa

Reputation: 4825

What OpenID Connect authorization flow should be used to secure Web API resources between an MVC client or its end-users?

What is the correct way to use IdentityServer3 and OpenID Connect (flow and configuration) in order to implement the following:

We have one MVC site Products and one Web API Products.API. We must secure all Web API endpoints:

  1. Some endpoints can and should only be accessible by the MVC application on behalf of an authenticated (logged on) user.

  2. Other endpoints, such as the ones used for account registration, password reset or anonymous operations, need to be authorized to the MVC client site directly, since there is no authenticated user in the picture.

We are currently using the Hybrid Flow, but this was mostly motivated after watching one of Dominick Baier videos. I've looked into https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c and it seems what we are looking is a combination of Client Credential Flow and Resource Owner Password Credential Flow, but I'm not sure I can even mix two flows as apparently it is not recommendable.

Upvotes: 0

Views: 128

Answers (1)

iandayman
iandayman

Reputation: 4467

You could split the API into a "service" type API and a "user" API and have separate auth flows but do you really need to have the 2 APIs?

Does the registration code really belong in the API? It sounds like the the MVC app (guessing that it is also your identity provider) should deal with account registration - this is normally a key separation in using Oauth2.0 : the API doesn't concern itself at all with user admin!

If you do refactor the registration functionality to sit with the identity provider / Auth server, then do you still have the need to have 2 auth flows?

If you do, you could use just the password flow and have a fake "admin" user setup in your identity system for the non-user context endpoints. Your MVC app can pass in the credentials for the "admin" user and the API can code for this specific user. It's horrible, I don't recommend it, but I've seen it work!

Upvotes: 1

Related Questions