oauth-v2-1
oauth-v2-1 copied to clipboard
oauth-wg
OAuth 2.1 is a consolidation of the core OAuth 2.0 specs
From RFC6749 Security Considerations > The authorization server SHOULD NOT process repeated authorization > requests automatically (without active resource owner interaction) > without authenticating the client or relying on other...
## I expect - application/x-www-form-urlencoded is a media type - IANA registration points to https://url.spec.whatwg.org/#application/x-www-form-urlencoded
Despite the specification explicitly stating "This is an Authorization Framework" as of OAuth 2.0, some Authorization Server/Resource Server and many Client developers have been using this for the purpose of...
In https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-07 section 5.2.3 (The WWW-Authenticate Response Header Field): > All challenges for this token type MUST use the auth-scheme value > Bearer. This scheme MUST be followed by one...
I apologize in advance for this one... I really do. It has always been my reading that OAuth 2.0 allows for client identification/authentication to be omitted in extension grants (if...
From RFC6749 Security Considerations > The authorization server SHOULD enforce explicit resource owner authentication and provide the resource owner with information about the client and the requested authorization scope and...
In [Section 5.2.1.1.](https://github.com/aaronpk/oauth-v2-1/blob/main/draft-ietf-oauth-v2-1.md#authorization-request-header-field) the syntax of `access_token` values that are used in the context of HTTP headers is explicitly outlined as follows: ``` b64token = 1*( ALPHA / DIGIT /...
## This PR - token encryption can't replace TLS unless similar requirements are implemented (integrity, privacy, authenticity) ; - suggest using TLS along the way, even when using TLS terminators;...
## This PR - reorganize Security considerations - remove redundancies - reference security considerations from other rfcs Needs #98