OAuth Event Types 1.0 Google
mscurtescu@google.com
Amazon
richanna@amazon.com
Oracle Corporation
phil.hunt@yahoo.com
Yubico
secevemt@ve7jtb.com
RISC Working Group This document defines the OAuth Event Types. Event Types are introduced and defined in Security Event Token (SET).
This specification is based on RISC Profile and uses the subject identifiers defined there. The aud claim identifies the OAuth 2 client and its value SHOULD be the OAuth 2 client id.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
This section defines OAuth specific Subject Identifier Types. Subject identifiers are defined in Section 2 of .
A Token Subject Identifier Type describes an OAuth 2 token subject and it is identified by the name oauth_token. Subject Identifiers of this type MUST contain the following claims: token_type - required, describes the OAuth 2 token type. Possible values: access_token authorization_code refresh_token token_identifier_alg - required, describes how is the token string in the token attribute to be interpreted. Possible values: plain - plain token string prefix - token string prefix hash_* - token string hash, actual hash algorithms added as a suffix. TODO: create individual values for each hash algorithm. token - required, the token identifier, as described by token_identifier_alg.
A Client Subject Identifier Type describes an OAuth 2 client subject and it is identified by the name oauth_client. Subjects identifiers of this type MUST contain the following claim: client_id - required, the OAuth 2 client id.
The base URI for OAuth Event Types is: https://schemas.openid.net/secevent/oauth/event-type/
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/token-issued Token Issued signals that a new token was issued. Attributes: subject - required, a Subjectect Identifier as defined by that identifies the token. token_subject - optional, a Subject Identifier as defined by Section 2.1 of that identifies the account associated with the token. TODO: OAuth flow and endpoints involved in the process? For example: redirect_uri, response_type, origin? The token SHOULD be uniquely identified by the provided attributes, either by subject alone or by subject in combination with token_subject. The token is unique in the context of a given Transmitter and not globally unique. TODO: do we need a iss attribute for the oauth_token Subject Type?
(the event type URI is wrapped, the backslash is the continuation character)
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/token-revoked Token Revoked signals that the token identified by this event was revoked. Attributes: subject - required, a Subjectect Identifier as defined by that identifies the token. token_subject - optional, a Subject Identifier as defined by Section 2.1 of that identifies the account associated with the token. reason - optional, the reason why the token was revoked. Possible values: inactive - token was revoked by the issuer because of inactivity too_many - token was revoked by the issuer because an internal limit was reached api - token was revoked through an API call like user - token was revoked explicitly by the user issuer - token was revoked by the issuer for some other reason TODO: add extension mechanism (either through URIs or IANA registry) The token SHOULD be uniquely identified by the provided attributes, either by subject alone or by subject in combination with token_subject. The token is unique in the context of a given Transmitter and not globally unique. TODO: do we need a iss attribute for the oauth_token Subject Type?
(the event type URI is wrapped, the backslash is the continuation character)
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/tokens-revoked Tokens Revoked signals that all tokens issued for the account identified by the subject have been revoked. Attributes: subject - optional, a Subject Identifier as defined by Section 2.1 of that identifies the account associated with the token. reason - optional, the reason why all the tokens were revoked. Possible values: user - all tokens were revoked explicitly by the user issuer - all tokens were revoked by the issuer TODO: add extension mechanism (either through URIs or IANA registry)
(the event type URI is wrapped, the backslash is the continuation character)
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/client-disabled Client Disabled signals that the client identified by the aud claim has been disabled. The client may be enabled in the future. Attributes: TODO use client subject identifier
(the event type URI is wrapped, the backslash is the continuation character)
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/client-enabled Client Enabled signals that the client identified by the aud claim has been enabled. Attributes: TODO use client subject identifier
Event Type URI: https://schemas.openid.net/secevent/oauth/event-type/client-credential-changed Client Credential Changed signals that one of the credentials of the client identified by the aud claim has changed. For example the client secret has changed. Attributes: TODO use client subject identifier
TODO: register oauth_token and oauth_client subject identifier types.
Security Event Token (SET) The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. OpenID RISC Profile of IETF Security Events 1.0 OAuth 2.0 Token Revocation This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.