(How) does one secure a Web API with OpenID Connect (or not?)

0
votes

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.

1
oauth-2.0asp.net-core-webapiopenid-connect

1 Answers

1
votes

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.