4 ms·

Regarding the access token... > the server does not have any secrets or passwords to compare with the submitted data, which means that it is implicitly truste

by progre 6y ago

Regarding the access token... > the server does not have any secrets or passwords to compare with the submitted data, which means that it is implicitly trusted The access token should be signed right? So it's not implicitly trusted. The server must of course validate the access token using the public key indicated in the token, and of course only accept tokens from trusted providers. Maybe I'm not reading this right.

UnlockedSecrets 6y ago
It can be authenticated as coming from a trusted party but cannot be authenticated against a user password because the system has no way of knowing any secrets provided by the user.
- progre 6y ago
  Well, that's kind of the point right? Keeping user secrets out of the trusting system.
mooreds 6y ago
That whole section is about the implicit grant anyway, which should be avoided. As far as validating tokens, access tokens are 'opaque' in OAuth2; the token format is not defined by the spec. (In OIDC, they are JSON web tokens.) For OAuth, you can make a call to the introspect endpoint and the Authorization Server will tell you if it is a valid token. In practice, OAuth servers often issue JWTs, and there's a draft spec out to make them interoperable: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-11 https://tools.ietf.org/html/draft-ietf-oauth-access-token-jw... If you are a resource server consuming an access token and you know the token is a JWT, you should check the following at a minimum: * the token is signed according to the algo and the key that you expect * the token is not expired (the `exp` claim) and is currently valid (the `nbf` claim, if present) * the token is issued by who you expect (the `iss` claim) (which is the point you are making about 'trusted providers') * the token is issued for you (the `aud` claim) Most libraries I have interacted with check the first two, but not the last two.
- progre 6y ago
  I didn't know the token format wasn't specified, thanks for the clarification! I've only ever come across JWT:s.
- cratermoon 6y ago
  > the token is signed according to the algo and the key that you expect Important point! Especially with JWT. It must be the algorithm you EXPECT, not the algorithm in the token. Someone flubbed up and made the "none" algorithm mandatory for spec-compliant implementations. Unfortunately, that can result in any JWT being treated as valid. It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature. There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good".
  - mooreds 6y ago
    > Someone flubbed up and made the "none" algorithm mandatory for spec-compliant implementations. Which spec are you referring to? 7519? Per section 6 ( https://tools.ietf.org/html/rfc7519#section-6 https://tools.ietf.org/html/rfc7519#section-6 ) "none" is an optional feature of JWT. I am not aware of any spec related to OAuth which requires a server to issue or accept a JWT with an algo of "none". Can you point one out to me? From the AS side, our product won't even allow you to "sign" a JWT with a value of none. I'm not sure about other authorization servers. And I always recommend that if a resource server ever sees an algorithm of "none" it should throw out the JWT full stop. > It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature. What is the way around this? Looks like Paseto tokens (an alternative I've heard mentioned) works by not allowing unsigned tokens: https://github.com/paragonie/paseto https://github.com/paragonie/paseto Is there another way to fix this? > There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good". Spooky! Can you share these so I can stay far away from them? :)
jayd16 6y ago
>As a result, this behavior can lead to a serious vulnerability if the client application doesn't properly check that the access token matches the other data in the request. Later they use this language the clarify the situation. I suppose the situation being described is when the token has no information that can track to a specific user id. I guess devs are just checking that a token decrypts and aren't verifying it matches the user id in the request? Seems like basic security 101.

by progre 6y ago

UnlockedSecrets 6y ago

It can be authenticated as coming from a trusted party but cannot be authenticated against a user password because the system has no way of knowing any secrets provided by the user.

progre 6y ago
Well, that's kind of the point right? Keeping user secrets out of the trusting system.

mooreds 6y ago

That whole section is about the implicit grant anyway, which should be avoided. As far as validating tokens, access tokens are 'opaque' in OAuth2; the token format is not defined by the spec. (In OIDC, they are JSON web tokens.) For OAuth, you can make a call to the introspect endpoint and the Authorization Server will tell you if it is a valid token. In practice, OAuth servers often issue JWTs, and there's a draft spec out to make them interoperable: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-11 https://tools.ietf.org/html/draft-ietf-oauth-access-token-jw... If you are a resource server consuming an access token and you know the token is a JWT, you should check the following at a minimum: * the token is signed according to the algo and the key that you expect * the token is not expired (the `exp` claim) and is currently valid (the `nbf` claim, if present) * the token is issued by who you expect (the `iss` claim) (which is the point you are making about 'trusted providers') * the token is issued for you (the `aud` claim) Most libraries I have interacted with check the first two, but not the last two.

progre 6y ago
I didn't know the token format wasn't specified, thanks for the clarification! I've only ever come across JWT:s.
cratermoon 6y ago
> the token is signed according to the algo and the key that you expect Important point! Especially with JWT. It must be the algorithm you EXPECT, not the algorithm in the token. Someone flubbed up and made the "none" algorithm mandatory for spec-compliant implementations. Unfortunately, that can result in any JWT being treated as valid. It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature. There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good".
- mooreds 6y ago
  > Someone flubbed up and made the "none" algorithm mandatory for spec-compliant implementations. Which spec are you referring to? 7519? Per section 6 ( https://tools.ietf.org/html/rfc7519#section-6 https://tools.ietf.org/html/rfc7519#section-6 ) "none" is an optional feature of JWT. I am not aware of any spec related to OAuth which requires a server to issue or accept a JWT with an algo of "none". Can you point one out to me? From the AS side, our product won't even allow you to "sign" a JWT with a value of none. I'm not sure about other authorization servers. And I always recommend that if a resource server ever sees an algorithm of "none" it should throw out the JWT full stop. > It's a chicken-and-egg problem that the designers missed: you can't trust the token until you've validated it, but you'd have to believe the value of the algo field before you've validated it in order to check the signature. What is the way around this? Looks like Paseto tokens (an alternative I've heard mentioned) works by not allowing unsigned tokens: https://github.com/paragonie/paseto https://github.com/paragonie/paseto Is there another way to fix this? > There are libraries that will see "none" in the algo field and treat that as "this token doesn't have a signature that needs to be validated, so it's good". Spooky! Can you share these so I can stay far away from them? :)

jayd16 6y ago

>As a result, this behavior can lead to a serious vulnerability if the client application doesn't properly check that the access token matches the other data in the request. Later they use this language the clarify the situation. I suppose the situation being described is when the token has no information that can track to a specific user id. I guess devs are just checking that a token decrypts and aren't verifying it matches the user id in the request? Seems like basic security 101.