0
votes

I have several REST APIs which I want to secure with a federated authorization server. This page: https://oauth.net/articles/authentication/ suggests that OAuth2 alone is not enough for authentication and one should use the OpenId Connect extension to get it right.

However, I have the feeling that what OIDC does is only defining an identity endpoint and the related scopes and claims. If I don't specifically need these identity claims, what's wrong with using plain OAuth authorization code for authenticating a user and protecting resource? Or is OAuth2 only for delegating access to a client app which works on behalf of the user (which is not my use cas)?

Thanks for the inputs!

2

2 Answers

0
votes

OAuth is an authorization framework. Before OpenID Connect, some organizations were increasingly using OAuth as an authentication mechanism just as you stated in your question. While this is technically possible, it is rife with inconsistencies between one implementation to the next. The standardization of this method came around with OpenID Connect, where this group of vendors essentially said let's come up with a standardized approach to what we have been doing. The benefits of a standardized approach is collaboration, security, etc. The openid scope of OAuth was born.

0
votes

Most end user authentication related work occurs on the UI side of things, and of course involves Authorization Redirects, Identity Providers, Consent Forms and so on.

In terms of the code for a Secured REST API you instead perform the following types of action. This is primarily OAuth 2.0 behaviour as you say, though Open Id Connect endpoints can be useful:

  • Validate received access tokens from the Authorization Server
  • Read token claims to identify the authenticated user
  • To do this you may need to download token signing keys from the JWKS endpoint
  • Your API can look up further details from the User Info endpoint
  • Your API can use the metadata endpoint to get the above endpoint locations
  • Your API will then apply authorization rules based on claims and scopes