Difference between revisions of "OAuth 2.0"
From MgmtWiki
(→Problems) |
(→Problems) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
==Problems== | ==Problems== | ||
| − | * OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until | + | * OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until [[Quantum Computing Threat]] arrives. |
* It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure. | * It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure. | ||
| − | * Token type "bearer" is still the only one used in real-world implementations. | + | * Token type "bearer" is still the only one used in real-world implementations. See the page [[Bearer Tokens Considered Harmful]] on this wiki. |
* The redirect URL is not well specified in the spec and is subject many exploits. The problem is poor implementations and reuse of each client id across many implementations. | * The redirect URL is not well specified in the spec and is subject many exploits. The problem is poor implementations and reuse of each client id across many implementations. | ||
* HTTP refer header is usually sent in the clear and contains way too much information in Front Channel implementations. | * HTTP refer header is usually sent in the clear and contains way too much information in Front Channel implementations. | ||
| Line 16: | Line 16: | ||
* Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security. | * Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security. | ||
* Resource Owner password turned into a really bad idea. It should be banned. | * Resource Owner password turned into a really bad idea. It should be banned. | ||
| − | * Scopes were created, but not defined, so there is no way to determine what a scope actually means. | + | * Scopes were created, but not explicitly defined, so there is no way to determine what a scope actually means. |
| + | * Discovery is not well defined, but always leaks information. | ||
==Solutions== | ==Solutions== | ||
| + | *Switch OAuth from [[Bearer Token]]s to [[Bound Token]]s | ||
| + | *Justin Richer has some suggestions.<ref>Justin Richer, ''Moving On from OAuth 2: A Proposal.'' https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade</ref> | ||
==References== | ==References== | ||
# RFC 6749 The OAuth 2.0 Authorization Framework specification | # RFC 6749 The OAuth 2.0 Authorization Framework specification | ||
# RFC 8252 OAuth 2.0 for Native Apps Specification | # RFC 8252 OAuth 2.0 for Native Apps Specification | ||
| + | # [[Proof Key for Code Exchange]] wiki page | ||
| + | # [https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce/?utm_campaign=text_website_all_multiple_dev_dev_oauth-pkce_null Proof Key for Code Exchange (PKCE)] - Micah Silverman Okta - ''Implement the OAuth 2.0 Authorization Code with PKCE Flow'' | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Standard]] | [[Category:Standard]] | ||
Latest revision as of 08:20, 28 April 2021
Full Title or Meme
The OAuth 2.0 Authorization Framework
Context
In OAuth 2.0
Problems
- OAuth 2.0 still depends on shared secrets between services on Web Sites and other internet devices;[1] while most sites are protected by public keys and certificates, at least until Quantum Computing Threat arrives.
- It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure.
- Token type "bearer" is still the only one used in real-world implementations. See the page Bearer Tokens Considered Harmful on this wiki.
- The redirect URL is not well specified in the spec and is subject many exploits. The problem is poor implementations and reuse of each client id across many implementations.
- HTTP refer header is usually sent in the clear and contains way too much information in Front Channel implementations.
- Security UX is complicated and not described in the spec.
- State parameters are needed for security, but not required by the spec.
- A bunch of specs implemented other ways to enable secure, such as UMA, PCKE, etc.
- Implicit flow was added to enable javascript, but recent innovations in browser has weaken the existing very weak security.
- Resource Owner password turned into a really bad idea. It should be banned.
- Scopes were created, but not explicitly defined, so there is no way to determine what a scope actually means.
- Discovery is not well defined, but always leaks information.
Solutions
- Switch OAuth from Bearer Tokens to Bound Tokens
- Justin Richer has some suggestions.[2]
References
- RFC 6749 The OAuth 2.0 Authorization Framework specification
- RFC 8252 OAuth 2.0 for Native Apps Specification
- Proof Key for Code Exchange wiki page
- Proof Key for Code Exchange (PKCE) - Micah Silverman Okta - Implement the OAuth 2.0 Authorization Code with PKCE Flow
