0

Is it recommended or good practice to protect a Web API directly with Open ID Connect or not? The setup:

  • Mobile App
  • Authorization Server (ADFS 4.0)
  • Web API (ASP.NET Core)

Currently I do the normal OAuth2 "Authorization Code Flow", and then pass the access_code to my Web API in the HTTP Header as "Authorization: Bearer ". In ASP.NET core I just do the usual services.AddAuthentication(...).AddJwtBearer(...) Works fine.

But everyone talks about OAuth2 beeing only "pseudo-authentication" with certain flaws. I want my Users to be a properly authenticated before using my Web API. So it seems like Open ID Connect should be the way to go, aka "real authentication".

But does it actually work to "consume" Open ID Connect authentication in an ASP.NET Core Web API? And if yes, how? And is it good practice? All samples seem to be about Web Sites, not Web APIs.

There is an extension method services.AddAuthentication(...).AddOpenIdConnect()

But here Implement OpenID connect Authetication in asp.net WEB API they state that "this component is designed for user interactive clients".

What i also don't understand, what would I do with the "id_token" I get from Open ID connect. Currently i just pass the "access_token" as Bearer. How do i consume the id_token?

Some clarifications:

  • The API does not act on behalf of a user (access to company data).
  • The API already has access to the "data". It does not require any auth workflows for itself nor does it need to pass the users credentials along.
  • The API needs to know "WHO" the user is, and it has to be done in an modern and good way
  • That's why I was thinking of OICD with its "real auth" (VS Oauth2-only which is "pseudo").

I basically cannot wrap my head around how the stuff returned from OICD (id_token) will be passed to my Web API.

hefeteig
  • 3
  • 3

1 Answers1

1

OIDC is an OAuth workflow. It merely extends OAuth; it is not a replacement for it. APIs are typically authorized either by token or client secret. The difference is simply whether it's acting on behalf of a specific user or not. For example, something like the Facebook API has both workflows for its API, you generally operate with Facebook's API as a client app using the app id and client secret for your app, or you can do user-specific things like create a post on the user's wall given an authorization token.

That authorization token almost invariably comes from an OAuth workflow. Given your stated setup, your mobile app would handle this to get an auth token for the user from your ADFS server. Your API, meanwhile, would actually probably do both. It would communicate both using an assigned client secret and a user auth token, if the mobile app provides it with one.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • Thx! To clarify my case a bit more: The API does not act on behalf of a user (access to company data). The API already has access to the "data". It does not require any auth workflows for itself. (It runs under AD Service Account with the required permissions). I basically just want a "secure" and state of the art way that Users coming from the Internet, authenticate themselves on the AD. That's why I was thinking of OICD with its "real auth" (VS Oauth2-only which is "pseudo"). I cannot wrap my head around how the stuff returned from OICD (id_token) will be passed to my Web API. – hefeteig Jan 29 '19 at 18:26
  • The only difference between traditional OAuth and OIDC is that OIDC is authorizing a particular app user via an external auth provider, whereas OAuth simply authorizes the app itself. I suppose that's where you're getting "real" vs "pseudo", but it's also why your question doesn't really make sense. Which you use boils down to what you need to do. – Chris Pratt Jan 29 '19 at 18:33
  • If your app has actual user accounts you need to work with, separate from what's in AD, then you use OIDC. If the app just needs to work on behalf of AD users, then OAuth. – Chris Pratt Jan 29 '19 at 18:35
  • Thanks again! Regarding your last comment, I think its neither: My app has no user accounts. Also it does not really work on behalf of the user (or at least that's what I'm thinking). Let's say I just want to know in my Web API: WHO (which AD Username) the current user is, let's say to just write into a logfile which API calls he made. I also need to be sure its really him, so he must have entered his AD password before somewhere. The user has no permission in my case. Not defined in the AD, not defined anywhere else. I just need to know its actually him, because he knew his password. – hefeteig Jan 29 '19 at 18:50
  • The whole "on behalf of" can be a little murky, but what you're describing is still essentially working on behalf of the user. You could look at it like the user must provide their username to the API calls so that it can be logged. By authorizing, the app does this on their behalf. – Chris Pratt Jan 29 '19 at 19:02
  • Ahhh I see, I was thinking about the term "on behalf of" in a too "classic" way probably. I accepted your answer, thanks again. So I guess I can omit the "scope=openid" as I also have no use for the id_token then. – hefeteig Jan 29 '19 at 19:16
  • Probably, but it doesn't really hurt to keep it. The problem with scopes is that if you need additional ones later, everyone must reauthorize. It's good to be reserved with scopes, but openid is virtually a gimme. – Chris Pratt Jan 29 '19 at 19:34