Nobody Cares About OAuth or OpenID Connect
Developers don’t care about OAuth or OpenID Connect. Learn why.
James Hickey
Good stuff Randall.
Similar to your main premise, (.NET) devs don’t want to roll-out their own task scheduler, queuing system, event broadcasting mechanism, etc. They just want to start building their app and create something useful for their customers.
That led me to build Coravel (https://github.com/jamesmh/… 
Okta seems to be doing a great job at making user management and “auth” (both 
) easy to use 
Fred
Great summary, fun read! We’ve been using Python Social Auth in our Django application and, unfortunately for us, we still had to dig down and understand how the library leverages OAuth and OpenID concepts to debug/extend our application. While it’d be ideal to simply use the library without knowing the details, even the most basic overview of OAuth and OpenID would help any developer.
p.s. I love the sketches!
markstos
Disappointed SAML didn’t make a cameo in the article.
Art Harchenko
What’s missing in the article is the fact that OIDC/Oauth2 provide ability to create SSO (single sign-on) conditions. If you are developing one app it’s ok to have local authentication. But if you are a corporation with 5, 6… 10 customer facing apps you haven’t start thinking about centralized IDaaS solution. This is where OIDC shines.
Mike Schwartz
I also agree that giving developers easy to use libraries (you don’t write your own database or messaging library, why would you write your own OAuth library?), and middleware services that do some of the heavy lifting is a good thing. Gluu has spent years developing the OXD middleware service to do some things in the background, like validating signtures, using private key authentication at the token endpoint, and following other good practices. Auth0 has also done a good job in this regard.
And you are certainly right that developers don’t generally care about all the risks that are mitigated by properly implementing an OAuth / OpenID Connect client. However… the organization that is protecting a user’s credentials, their personal information, and their resources… they MUST care.
If you are a developer, and your code is responsible for leaking personal information… it has a financial impact on the organization for which you’re working. And it also has an impact on the person whose information is leaked. So to be a responsible developer, while it may be desirable to wash your hands of the whole thing, you need to practice a minimal level of security hygiene. Even if you use helper middleware services, excellent client software, or web filters (like mod_auth_openidc), you need to understand some of the basic security issues around federated identity. Knowing nothing is the equivalent of developer malpractice.
Anything unfamiliar is complex. OAuth is not inherently more complex then many of the things developers do. The technology in my phone is magic. Redirecting a user to a web page with a few parameters is significantly less mysterious.
One of the reasons I published my book Securing the Permeter, was to explain the concepts in simpler terms.
But what is both unproductive and detrimental to the industry is disparaging the good work that has been done.
Yes, please keep innovating. Come up with a better solution. I’d love to see an idenitty layer that does not rely on the web browser redirect. Someone, please invent that!!! But until that time, we need to support the best solutions we have today.
The question is what is the minimum amount of information that a developer needs to know? And that depends on a few things. How much personal information may be exposed in a breach, and how sensitive is that information? What is the transaction value of the resource being protected? How likely is an attack? What is the tangential impact of an attack? Based on the answer to these questions, developers can figure out how deep they need to go into the weeds.
@markstos : OpenID Connect is basically OAuth SAML. Completed in 2006, SAML did not think about things like SPA’s or mobile phones (iPhone came out in 2007…). SAML defines an identity assertion–it’s a signed XML document that tells you things like who the person is and how they were authenticated. OpenID Connect also defines an identity assertion, called the id_token. Instead of signed XML document, it’s a signed JSON document. But it contains basically the same information. I would think that consuming JSON documents is not too complicated for developers. And validating signatures does not seem inordinately complex either. It’s easier then XML canonicalization, which has been fraught with parser library risk.
Eleni Lixourioti
I’ve run into very similar problems that made me regret using a 3rd-party library. And I have yet to find a python application that didn’t run very early into problems with the out-of-the-box social auth packages when it came to extending behaviour 
Matthew O.
I’m just now learning OIDC and it’s very frustrating. I’d rather stick with saml cause it’s the devil I know.
xealgo
I recently implemented Github oauth and started to think “well shit, if this token ever leaked, people would be able to pull down someone’s private repos…I don’t even need to send my app creds when making subsequent api calls…”. So I decided to encrypt the token before storing it.
Rich Levinson
Even this extremely helpful article does not explain the “why?”.
We need to understand “why” do users need to log into a client application, and how that login relates to any server side appl that the cli-side app needs to access.
i.e. does the idp know about both the cli-side and svr-side apps?
i.e. if the user logs in to the cli-side app, how is the idp in a position to grant a token to the cli-side app that will give access to the svr-side app?
I mean even if the user logs into the idp based on the cli-side app’s redirect, how is this logging in to the cli-side app? If the idp knows the cli-side app, then how does the idp know that the user even has access to the svr-side app that the cli-side is requesting access to. i.e. how is the idp in a position, even if it knows the user, to grant access to some svr-side app that the cli-side app is asking about.
Is this explained in any of the oauth specs or oidcs specs? No.
If you buy a book on oauth/oidc does it explain any of this? No.
I am still trying to figure it all out.
Scott Brady
I disagree. Developers do care about OAuth and OpenID Connect: https://www.scottbrady91.co…
Gusztáv Varga
Or at least they should 
I strongly agree with your response.
Randall has a nice summary here, but I think the conclusion is a bit unforunate. Who else should be thinking about what happens in their systems if not the devs? Especially if it’s exactly the same thing that you do when e.g. you enter your office and use your ID card
Btw, imho the protocols are not complicated, but “just” complex and actually brilliant
Gusztáv Varga
Well, you don’t need that login, strictly speaking. Core OAuth 2.0 and OIDC has nothing to do with authenticated sessions, as it’s not their concern They only care about delegated authorization and authentication.
I think the OAuth 2.0 intro sums it up nicely: https://tools.ietf.org/html… The key is who trusts what initially.
This article describes why this is not enough purely for authentication: https://oauth.net/articles/…
Then you can add e.g. session management on top of all these: https://openid.net/specs/op…
Most of the implementations out there solve all these problems in a single entity, but I think it is important to see that these are very different use cases, even if somewhat related.
Eric Kufrin
I agree that we dont want our developers to have to understand the finer details of Oauth vs OIDC.
What we really care about is that they consume our IAM service and use any/one of the available protocols. Where we struggle is providing them guidance on the exact grant type for their use case and then subsequently providing sample code for that grant type.
We would prefer to give developers a decision tree and links to sample code for the resulting choice.
Rich Levinson
Thanks for the ref to the “not enough purely for authentication” article, Gustav.
it cleared up a lot for me - namely that I think the way the terminology about authn has been used if very ambiguous. OIDC doesn’t do any authentication, although it’s talked about as adding authentication to OAuth. What it does do is gather some info from the azsvr about the user that is not needed to complete the request to get the resource on the user’s behalf. It doesn’t need an IdToken for that.
Furthermore, OIDC relies on the authentication of the user that the azsvr did, and is just trying to get more info on the user in the process having nothing to do w the client getting access to the user’s resource.
This is what I have thought for a while although it is hard to get info about this perspective.
Another area is, ok, so the client got the IdToken, what’s it going to do w it? It doesn’t need to send it to the resource server, although maybe it could be used in lieux of a session cookie to establish a session with the resource server.
There are undoubtedly lots of legitimate applications the client can use the IdToken for.
The client is relying on the azsvr’s authn of the user in the process of obtaining the aztoken, and getting an IdToken to augment the client’s knowledge of the user.
Question is can this client then use the IdToken as an authentication credential w other apps? I don’t think it should, but maybe people use it that way?
Gusztáv Varga
Indeed, you can also think of OIDC as it has one single core resource, and it’s the identity of the user. It needs an ID Token to encapsulate that information, because in OAuth 2.0 the Access Token is opaque to the client. That is one of the main differences, for access tokens the token audience is the resource server, while for id tokens it’s the client.
OIDC has extensions for getting user profile data as well, but those require access tokens, as they are actually resources. Like at the company I work for I am an employee, a developer and a customer. I have a single identity, but several different profiles and usually different related metadata for each of them. Client apps get the identity and the profile data in separate calls as they are separate entities. You’re right, in typical systems all this have to be solved, but OAuth 2.0 and OIDC does not care about like roles and profiles.
As detailed above, ID Tokens have the sole puropose originally to provide the identity of the end user at the time of the authentication. As such, they typically can be discarded right after verification and parsing (e.g. save the identity IDs to your login session and you’re good to go), to reflect that they usually have much shorter validity than access tokens (e.g. 5 mins vs 1 hour) and you cannot use refresh tokens to refresh them. You cannot use them to access other resources (as the target audience is the client app, not the resources) but there are several extension use cases:
- You can use them for session management with the original OP. You can use a valid (even expired) ID Token to query if a central session has changed so e.g. you can sync logout across different client apps. Also, you can use it e.g. for initiating a logout without a confirmation if you present a valid ID Token.
- You can use them for identity federation between different providers. If they trust each other, one provider can get you an identity in it’s own context based on another system’s ID Token.
Rich Levinson
Very interesting, I appreciate the detailed response.
One thing I am wondering: if a client gets an access token for App-1, plus an
ID Token from OP-1, then it does not need the ID Token to get the resource from App-1,
but it can use the ID Token for “federation”.
Let’s say the client then needs to get a resource from App-2, which is served by
a different OP-2, then wouldn’t the client just get redirected to OP-2 by the App-2,
and the user need to grant access thru OP-2’s authn mechanism.
Or does the ID Token come into play here somehow?
Gusztáv Varga
Indeed, ID tokens serve both purposes really well, either help with setting up an authenticated session for an application (aka log in :), then through the various OIDC extensions, SSO, session management), or for federated identity.
In your example, if I need a resource from App-2 served by OP-2, and OP-2 trusts OP-1 (e.g. a well-known social provider), it simply redirects there for the authentication part, which is represented by an OP-1 id token, and once it knows the OP-1 identity, it can convert it to its own OP-2 identity (e.g. an OP-2 id token based on the above), and grant access to resources like App-2. If you are already “logged on” with OP-1, it can even be transparent to the end user.
Sorry for the late reply
Eldar I
Year 2020: my colleges are obsessed with SAML
Travis Fischer
This was an excellent breakdown and summary of a complex topic. Much thanks! 