OAuth Security 4 Dummies
OAuth 2.0 Security for Dummies
Day/Session:Thursday 1B
Convener:Torsten Lodderstedt
Notes-taker(s): Torsten Lodderstedt
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Torsten presented the recommendations outlined in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08
Link to his slides are available here: https://de.slideshare.net/TorstenLodderstedt/oauth-security-4-dummies-iiw27
Notes:
-- Redirect URI matching
Q: Does this document replace RFC 6819?
A: It will be an enhancement.
Q: We have many customers, who do not want to match the entire URL but only the hostname part. What would you tell them?
A: The exact redirect URI matching helps against open redirection. It is also about leaking URLs in refer headers
This was also behind the attack against ESPN.
When we say use a whitelisted URL then part of the guidance should also be to use the state parameter to convey information to get back to where they want to be.
Q: We have so many redirects and we cannot manage whitelists for all of them.
A: Maybe there is a need for text about how to solve the use case.
A: In SAML we have been using the cookie to determine where the user originally came from and to make sure that he / she get back to the starting page.
-- State parameter for XSRF prevention
Q: What do you mean by PKCE or nonce?
A: Nonce is from the OpenID Connect world and is not available in OAuth. PKCE wasn't intented for this purpose but it also provides the same protection capabilities. It is not exactly the same functionality.
A: From a spec point of view it would be better to just recommend PKCE since it applies to all OAuth deployment.
-- Mix-up prevention
(AS-specific redirect URIs: The client needs to remember what AS it talked to and when the redirect comes back it matches it against the stored value.)
Some groups use the state parameters to restore the proper state the client was previously. State is very flexible and useful. It is also used as a an XSRF. The use of the state value is referenced.
Hans mentioned that there is a draft about the state parameter encoded as a JWT:
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08
It is currently expired.
-- Token Reply
Recommendation is to bind the access token to certain originators.
Q: In a lot of distributed system the refresh token exchange is handled by one system and the access token exchange is handled by a different system. I am retrieving contact info and email. The systems are independent services. I have a central token management service. The client is a collection of distributed system. How do TLS-based apply in such a world?
A: I don't think they would work. We don't have anything today that secures this model.
A: Drawing was created. <<figure goes in here>>
Suggestion to turn the token service into a proxy, which could make handling more difficult.
All requests would go through the proxy. There are, however, different scalability considerations.
Q: Could we use Token Exchange as an alternative?
A: Token exchange is yet another way to get more access tokens.
The question is also who is making the exchange.
Another architecture is being presented by Justin, which required more protocol exchanges but was more secure.
You need to understand your downstream dependency chain in the application.
<<Figure 2 goes in here>>
Justin wrote a draft about exchanging an access token against another access token in
https://tools.ietf.org/html/draft-richer-oauth-chain-00
Torsten mentioned that they implemented a similar service without having to understand the downstream dependency in the application but rather in the AS.
At the OAuth 2.0 level you need some "smartness" to implement these features.
Torsten says that the use of token binding with certificates is a recommendation and works fine in simple scenarios.
-- Access Token Privilege Restriction
Restrictions about resource server and action. It is not easy to implement but possible.
Any time I need an access token I need to get back to the AS to create an access token for a particular purpose.
If a mobile app wants to back to 15 different services then the mobile app needs to request lots of tokens (particularly when tokens have a short lifetime).
There is no way for the client to mint a derived tokens, with the limited scope. Torsten, you are suggesting to be Zero Knowledge Proofs.
Aaron asks what attacks are prevented by these restrictions. Privilege escalation attacks are prevented.
It would be important to point this threat out. Torsten says it is in there.
Q: Putting a URL in there is more restrictive; using a logical name is more practical
A: It is more difficult to have a logical location for practical purposes and for security matching.
A: Justin suggests to use both.
<<< Torsten wrote down notes about token leakage prevention. >>>
Q: Hasn't the audience been part of scope?
A: No, the scope parameter has been rather unspecified.
