4 ms·
It seems strange to publish a “modern guide to OAuth” without at least a nod to OpenID connect. Disclaimer: skimmed the overview. Currently reading the whole th
by catlifeonmars 6y ago
It seems strange to publish a “modern guide to OAuth” without at least a nod to OpenID connect. Disclaimer: skimmed the overview. Currently reading the whole thing.
- mooreds 6y agoYes, I said the same thing to my co-author. He talks to a ton of customers and said that in his experience most people don't talk about OIDC separately from OAuth, and that they conflate the two. Most OAuth servers that someone is going to consider as an auth system (authentication, authorization, user management) are going to include OIDC.
- catlifeonmars 6y agoOh that’s interesting. This is purely anecdotal evidence with small n, but: 1) I concur that Oauth2 and OIDC are often conflated, and then contrasted to SAML and single-sign on (also conflated). 2) No one wants to manage identity (federation by default), but almost everyone wants to manage authorization. This makes sense, since authorization is strongly related to business logic.
- mooreds 6y ago> This makes sense, since authorization is strongly related to business logic. Definitely. I'd say you could further break authorization into two components: * what permissions/roles a user should have * what those permissions/roles can do in an application The former is somewhat amenable to being centralized in a user management application. The latter is always going to be application dependent and should be handled inside an application's business logic (perhaps abstracted to a central component there).