CODEWITHSUNDEEP
oauth-2.0oauthsingle-sign-onopenid-connect
Whimusical
Whimusical

Reputation: 6649

Does OAUTH and OIDC make sense in a scenario when you need Single-Sign On on a microservices mesh and every one of these is owned by same company?

From theoretical point of view, it looks like it fits the scenario to have descentralized authorization consumed by multiple resource servers. But then when analyzing the intention behind "scopes", I am not that sure. Because the typical usecase I always see is telling a third-party app what data can consume (R/W) on other (micro)services of auth server's company.

Is disregarding scopes a sign of misusing Oauth2/OIDC? Or is using scopes in the following way (microservice1:read, microservice2:write) or (microservice1:big_role, microservice2:admin_role) also perverting the purpose?

Upvotes: 0

Views: 54

Answers (1)

Gary Archer
Gary Archer

Reputation: 29243

Ultimately I like to think of OAuth in these terms:

  • Managing Data Security
  • Enabling modern and productive apps

Microservices Security

Most software companies build APIs, Web UIs and Mobile UIs. The OAuth family of technologies provides options for securing all of them based on modern JSON based messages.

In doing so you can externalise some of the really hard stuff such as multi factor authentication, managing privacy and auditing. OAuth also tends to fit well with general architecture goals such as performance.

Scopes

These represent areas of data and what you can do with the data, as described in This Curity Article. There is nothing wrong in using scopes in a basic way to start with, then gradually evolving scopes based on data sensitivity and who the client is.

Summary

There is a learning curve to OAuth, but once done your apps tend to have the best capabilities.

Upvotes: 2

Related Questions