4 ms·

The token can be a opaque string but doesn't have to be. Often, it's a JWT which can be decoded, validated, and used locally without a trip to the auth server.

The token can be a opaque string but doesn't have to be. Often, it's a JWT which can be decoded, validated, and used locally without a trip to the auth server. It looks like Vidio, etc validated the signature of the JWT properly but didn't check the "aud" or audience claim, which defines who should use it. Therefore, it was a valid token, it was for the target user, but the token itself wasn't for Vidio. It's the equivalent of buying a ticket for a United Airlines flight, going to the airport, and United letting you get on ANY flight because you have a valid ticket. Background: I helped build the Okta OAuth product (not related to the breaches) and I'm the author of the top OAuth/OIDC course on linkedIn.

withinboredom 3y ago
Heh, this is exactly how I got on the wrong flight once (the gate changed and I didn’t realize it), the machine didn’t tell the person I was getting on the wrong flight and the attendant didn’t notice. The only reason I discovered I was on the flight is because someone else had a ticket for my seat. The security people were very curious how I did it, both pilots were very pissed (both flights had to be stopped from leaving the gate until they were sure I didn't leave a bag on one of the flights, yay terrorism). But now you can’t do that any more.
magicalhippo 3y ago
Not just aud, but also issuer and you should check it was signed by a proper certificate no? https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens#validate-tokens https://learn.microsoft.com/en-us/entra/identity-platform/ac...
- vladvasiliu 3y ago
  Indeed. In my case, I was initially confused by the fact that in most examples (specifically for Azure AD, which is what I've used), they give you an access token for another app, here MS Graph API. It specifically says you're not supposed to read that access token, so you can't validate it. You should use the ID token instead (which can be validated), but in the default configuration, the ID token doesn't carry much information, so you need to call the `userinfo` endpoint with said opaque access token.
  - PeeMcGee 3y ago
    For Microsoft it's another case of them going out of their way to exercise every possible inch of lee-way permitted by the specifications. No one in their right mind should expect a userinfo endpoint to only be accessible at an entirely different host. It's doubly stupid that Azure AD provides no other options for remote token validation, conveniently skipping the token introspection extension that _every other IdP supports._ People writing OAuth2 clients reasonably assume that trustworthy IdP's will behave normally and predictably, which means Azure AD/Graph(/Entra ID?) is probably not compatible with the libraries you're using. Fortunately Microsoft provides their own perplexing, over-engineered SDK for a handful of languages. All you have to do is rip apart your existing OAuth2 plumbing and carve another Microsoft-sized hole into your otherwise nice and standardized application.
    - vladvasiliu 3y ago
      In my case, for apps that only need to authenticate users with AzureAD, I've added the required information to the tokens and called it a day. I wouldn't bet the farm on it, but I seem to remember that by default, the mozilla-oidc implementation for Django was expecting an userinfo-like endpoint. And I remember wasting an unbelievable amount of time trying to figure how to add information to that endpoint. I've never found anything, I just patched the lib to retrieve the relevant fields from the tokens.
- jillesvangurp 3y ago
  Depends. The core issue is that a lot of developers confuse authentication and authorization. And oauth kind of muddles the water on that front by vaguely doing both but not really. All it does really is exchange tokens (assertions). Anything JWT related is orthogonal to oauth. Oauth does not actually provide any semantics for the tokens you exchange. They might be JWTs and you might be able to verify them. Or they might just be some random number, a hash, or some kind of database id. But you would have to know in advance what it is exactly and what the proper process for verifying the token is. In the case of a random number or some kind of session id, the process of verifying that token would involve looking it up from some kind of database or via some kind of API. Alternatively, with a JWT, it might be a signed one (hopefully) and you'd be able to check the signature if you have the public key. All you have at this point is a blob that was signed by someone that you might or might not trust. The claims and other meta data in the token would tell you hopefully who the person is (authentication) and the level of access they might be given (authorization). The JWT spec defines some fields that you might use for that. But it's up to you to check all those things and verify them. The point is, that a lot of this stuff is simply implementation/vendor specific and you just need to know what to check and how and why. And it's on you to do all those things. This is not an issue with oauth, or JWTs, but with incompetent developers doing things wrong or being lazy/negligent/indifferent. Which sadly is very common. Lots of people that get busy implementing all sorts of stuff without any formal training. And a lot of this stuff isn't even taught properly in schools/universities. This falls in the same category as putting passwords plain text in a database, not setting up ssl certificates, running your database on an open port on the internet, and similar things that developers do wrong all the time. Because they don't even know the basics of how to do things right. A lot of these things would be caught during any half decent audit. And quite a few of those things could expose the companies involved to some expensive law suits. Which is why lots of companies spend money on audits because they don't like expensive law suits.
  - arka2147483647 3y ago
    Nope. The thing about cryptography you always hear being said is "don't roll your own crypto", because you don't know all the complexities and failure modes that experts have researched. In o-auth, just you comment mentions multiple ways of doing things, and different responsibilities the developers have in different circumstances. Essentially the developer is forced roll some of their own auth. Compare that, for example, to say how you use TLS. You just use the standard libs bundled everywhere, and open connection, and the the system does all the validation for you. The complexity is there, but average developer is not expected to understand it. O-auth simply exposes too many details to the average developer, and too many options to use them differently, for it to ever be secure.
- caseysoftware 3y ago
  The articles say these sites were validating the tokens - as in checking signatures - so they were doing that properly. The issuer is another matter. Facebook or any other social provider is different than using AD. With AD, every customer would have a separate and distinct issuer related to their specific org and config. For social auth, there would be ONE issuer that everyone shares.

withinboredom 3y ago

Heh, this is exactly how I got on the wrong flight once (the gate changed and I didn’t realize it), the machine didn’t tell the person I was getting on the wrong flight and the attendant didn’t notice. The only reason I discovered I was on the flight is because someone else had a ticket for my seat. The security people were very curious how I did it, both pilots were very pissed (both flights had to be stopped from leaving the gate until they were sure I didn't leave a bag on one of the flights, yay terrorism). But now you can’t do that any more.

magicalhippo 3y ago

Not just aud, but also issuer and you should check it was signed by a proper certificate no? https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens#validate-tokens https://learn.microsoft.com/en-us/entra/identity-platform/ac...

vladvasiliu 3y ago
Indeed. In my case, I was initially confused by the fact that in most examples (specifically for Azure AD, which is what I've used), they give you an access token for another app, here MS Graph API. It specifically says you're not supposed to read that access token, so you can't validate it. You should use the ID token instead (which can be validated), but in the default configuration, the ID token doesn't carry much information, so you need to call the `userinfo` endpoint with said opaque access token.
- PeeMcGee 3y ago
  For Microsoft it's another case of them going out of their way to exercise every possible inch of lee-way permitted by the specifications. No one in their right mind should expect a userinfo endpoint to only be accessible at an entirely different host. It's doubly stupid that Azure AD provides no other options for remote token validation, conveniently skipping the token introspection extension that _every other IdP supports._ People writing OAuth2 clients reasonably assume that trustworthy IdP's will behave normally and predictably, which means Azure AD/Graph(/Entra ID?) is probably not compatible with the libraries you're using. Fortunately Microsoft provides their own perplexing, over-engineered SDK for a handful of languages. All you have to do is rip apart your existing OAuth2 plumbing and carve another Microsoft-sized hole into your otherwise nice and standardized application.
  - vladvasiliu 3y ago
    In my case, for apps that only need to authenticate users with AzureAD, I've added the required information to the tokens and called it a day. I wouldn't bet the farm on it, but I seem to remember that by default, the mozilla-oidc implementation for Django was expecting an userinfo-like endpoint. And I remember wasting an unbelievable amount of time trying to figure how to add information to that endpoint. I've never found anything, I just patched the lib to retrieve the relevant fields from the tokens.
jillesvangurp 3y ago
Depends. The core issue is that a lot of developers confuse authentication and authorization. And oauth kind of muddles the water on that front by vaguely doing both but not really. All it does really is exchange tokens (assertions). Anything JWT related is orthogonal to oauth. Oauth does not actually provide any semantics for the tokens you exchange. They might be JWTs and you might be able to verify them. Or they might just be some random number, a hash, or some kind of database id. But you would have to know in advance what it is exactly and what the proper process for verifying the token is. In the case of a random number or some kind of session id, the process of verifying that token would involve looking it up from some kind of database or via some kind of API. Alternatively, with a JWT, it might be a signed one (hopefully) and you'd be able to check the signature if you have the public key. All you have at this point is a blob that was signed by someone that you might or might not trust. The claims and other meta data in the token would tell you hopefully who the person is (authentication) and the level of access they might be given (authorization). The JWT spec defines some fields that you might use for that. But it's up to you to check all those things and verify them. The point is, that a lot of this stuff is simply implementation/vendor specific and you just need to know what to check and how and why. And it's on you to do all those things. This is not an issue with oauth, or JWTs, but with incompetent developers doing things wrong or being lazy/negligent/indifferent. Which sadly is very common. Lots of people that get busy implementing all sorts of stuff without any formal training. And a lot of this stuff isn't even taught properly in schools/universities. This falls in the same category as putting passwords plain text in a database, not setting up ssl certificates, running your database on an open port on the internet, and similar things that developers do wrong all the time. Because they don't even know the basics of how to do things right. A lot of these things would be caught during any half decent audit. And quite a few of those things could expose the companies involved to some expensive law suits. Which is why lots of companies spend money on audits because they don't like expensive law suits.
- arka2147483647 3y ago
  Nope. The thing about cryptography you always hear being said is "don't roll your own crypto", because you don't know all the complexities and failure modes that experts have researched. In o-auth, just you comment mentions multiple ways of doing things, and different responsibilities the developers have in different circumstances. Essentially the developer is forced roll some of their own auth. Compare that, for example, to say how you use TLS. You just use the standard libs bundled everywhere, and open connection, and the the system does all the validation for you. The complexity is there, but average developer is not expected to understand it. O-auth simply exposes too many details to the average developer, and too many options to use them differently, for it to ever be secure.
caseysoftware 3y ago
The articles say these sites were validating the tokens - as in checking signatures - so they were doing that properly. The issuer is another matter. Facebook or any other social provider is different than using AD. With AD, every customer would have a separate and distinct issuer related to their specific org and config. For social auth, there would be ONE issuer that everyone shares.