tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6819

 Errata 
Informational
Pages: 71
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: OAUTH

OAuth 2.0 Threat Model and Security Considerations

Part 1 of 3, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)               T. Lodderstedt, Ed.
Request for Comments: 6819                           Deutsche Telekom AG
Category: Informational                                       M. McGloin
ISSN: 2070-1721                                                      IBM
                                                                 P. Hunt
                                                      Oracle Corporation
                                                            January 2013


           OAuth 2.0 Threat Model and Security Considerations

Abstract

   This document gives additional security considerations for OAuth,
   beyond those in the OAuth 2.0 specification, based on a comprehensive
   threat model for the OAuth 2.0 protocol.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6819.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................6
   2. Overview ........................................................7
      2.1. Scope ......................................................7
      2.2. Attack Assumptions .........................................7
      2.3. Architectural Assumptions ..................................8
           2.3.1. Authorization Servers ...............................8
           2.3.2. Resource Server .....................................9
           2.3.3. Client ..............................................9
   3. Security Features ...............................................9
      3.1. Tokens ....................................................10
           3.1.1. Scope ..............................................11
           3.1.2. Limited Access Token Lifetime ......................11
      3.2. Access Token ..............................................11
      3.3. Refresh Token .............................................11
      3.4. Authorization "code" ......................................12
      3.5. Redirect URI ..............................................13
      3.6. "state" Parameter .........................................13
      3.7. Client Identifier .........................................13
   4. Threat Model ...................................................15
      4.1. Clients ...................................................16
           4.1.1. Threat: Obtaining Client Secrets ...................16
           4.1.2. Threat: Obtaining Refresh Tokens ...................17
           4.1.3. Threat: Obtaining Access Tokens ....................19
           4.1.4. Threat: End-User Credentials Phished Using
                  Compromised or Embedded Browser ....................19
           4.1.5. Threat: Open Redirectors on Client .................20
      4.2. Authorization Endpoint ....................................21
           4.2.1. Threat: Password Phishing by Counterfeit
                  Authorization Server ...............................21
           4.2.2. Threat: User Unintentionally Grants Too
                  Much Access Scope ..................................21
           4.2.3. Threat: Malicious Client Obtains Existing
                  Authorization by Fraud .............................22
           4.2.4. Threat: Open Redirector ............................22
      4.3. Token Endpoint ............................................23
           4.3.1. Threat: Eavesdropping Access Tokens ................23
           4.3.2. Threat: Obtaining Access Tokens from
                  Authorization Server Database ......................23
           4.3.3. Threat: Disclosure of Client Credentials
                  during Transmission ................................23
           4.3.4. Threat: Obtaining Client Secret from
                  Authorization Server Database ......................24
           4.3.5. Threat: Obtaining Client Secret by Online Guessing .24

Top      ToC       Page 3 
      4.4. Obtaining Authorization ...................................25
           4.4.1. Authorization "code" ...............................25
                  4.4.1.1. Threat: Eavesdropping or Leaking
                           Authorization "codes" .....................25
                  4.4.1.2. Threat: Obtaining Authorization "codes"
                           from Authorization Server Database ........26
                  4.4.1.3. Threat: Online Guessing of
                           Authorization "codes" .....................27
                  4.4.1.4. Threat: Malicious Client Obtains
                           Authorization .............................27
                  4.4.1.5. Threat: Authorization "code" Phishing .....29
                  4.4.1.6. Threat: User Session Impersonation ........29
                  4.4.1.7. Threat: Authorization "code" Leakage
                           through Counterfeit Client ................30
                  4.4.1.8. Threat: CSRF Attack against redirect-uri ..32
                  4.4.1.9. Threat: Clickjacking Attack against
                           Authorization .............................33
                  4.4.1.10. Threat: Resource Owner Impersonation .....33
                  4.4.1.11. Threat: DoS Attacks That Exhaust
                            Resources ................................34
                  4.4.1.12. Threat: DoS Using Manufactured
                            Authorization "codes" ....................35
                  4.4.1.13. Threat: Code Substitution (OAuth Login) ..36
           4.4.2. Implicit Grant .....................................37
                  4.4.2.1. Threat: Access Token Leak in
                           Transport/Endpoints .......................37
                  4.4.2.2. Threat: Access Token Leak in
                           Browser History ...........................38
                  4.4.2.3. Threat: Malicious Client Obtains
                           Authorization .............................38
                  4.4.2.4. Threat: Manipulation of Scripts ...........38
                  4.4.2.5. Threat: CSRF Attack against redirect-uri ..39
                  4.4.2.6. Threat: Token Substitution (OAuth Login) ..39
           4.4.3. Resource Owner Password Credentials ................40
                  4.4.3.1. Threat: Accidental Exposure of
                           Passwords at Client Site ..................41
                  4.4.3.2. Threat: Client Obtains Scopes
                           without End-User Authorization ............42
                  4.4.3.3. Threat: Client Obtains Refresh
                           Token through Automatic Authorization .....42
                  4.4.3.4. Threat: Obtaining User Passwords
                           on Transport ..............................43
                  4.4.3.5. Threat: Obtaining User Passwords
                           from Authorization Server Database ........43
                  4.4.3.6. Threat: Online Guessing ...................43
           4.4.4. Client Credentials .................................44

Top      ToC       Page 4 
      4.5. Refreshing an Access Token ................................44
           4.5.1. Threat: Eavesdropping Refresh Tokens from
                  Authorization Server ...............................44
           4.5.2. Threat: Obtaining Refresh Token from
                  Authorization Server Database ......................44
           4.5.3. Threat: Obtaining Refresh Token by Online
                  Guessing ...........................................45
           4.5.4. Threat: Refresh Token Phishing by
                  Counterfeit Authorization Server ...................45
      4.6. Accessing Protected Resources .............................46
           4.6.1. Threat: Eavesdropping Access Tokens on Transport ...46
           4.6.2. Threat: Replay of Authorized Resource
                  Server Requests ....................................46
           4.6.3. Threat: Guessing Access Tokens .....................46
           4.6.4. Threat: Access Token Phishing by
                  Counterfeit Resource Server ........................47
           4.6.5. Threat: Abuse of Token by Legitimate
                  Resource Server or Client ..........................48
           4.6.6. Threat: Leak of Confidential Data in HTTP Proxies ..48
           4.6.7. Threat: Token Leakage via Log Files and
                  HTTP Referrers .....................................48
   5. Security Considerations ........................................49
      5.1. General ...................................................49
           5.1.1. Ensure Confidentiality of Requests .................49
           5.1.2. Utilize Server Authentication ......................50
           5.1.3. Always Keep the Resource Owner Informed ............50
           5.1.4. Credentials ........................................51
                  5.1.4.1. Enforce Credential Storage
                           Protection Best Practices .................51
                  5.1.4.2. Online Attacks on Secrets .................52
           5.1.5. Tokens (Access, Refresh, Code) .....................53
                  5.1.5.1. Limit Token Scope .........................53
                  5.1.5.2. Determine Expiration Time .................54
                  5.1.5.3. Use Short Expiration Time .................54
                  5.1.5.4. Limit Number of Usages or One-Time Usage ..55
                  5.1.5.5. Bind Tokens to a Particular
                           Resource Server (Audience) ................55
                  5.1.5.6. Use Endpoint Address as Token Audience ....56
                  5.1.5.7. Use Explicitly Defined Scopes for
                           Audience and Tokens .......................56
                  5.1.5.8. Bind Token to Client id ...................56
                  5.1.5.9. Sign Self-Contained Tokens ................56
                  5.1.5.10. Encrypt Token Content ....................56
                  5.1.5.11. Adopt a Standard Assertion Format ........57
           5.1.6. Access Tokens ......................................57

Top      ToC       Page 5 
      5.2. Authorization Server ......................................57
           5.2.1. Authorization "codes" ..............................57
                  5.2.1.1. Automatic Revocation of Derived
                           Tokens If Abuse Is Detected ...............57
           5.2.2. Refresh Tokens .....................................57
                  5.2.2.1. Restricted Issuance of Refresh Tokens .....57
                  5.2.2.2. Binding of Refresh Token to "client_id" ...58
                  5.2.2.3. Refresh Token Rotation ....................58
                  5.2.2.4. Revocation of Refresh Tokens ..............58
                  5.2.2.5. Device Identification .....................59
                  5.2.2.6. X-FRAME-OPTIONS Header ....................59
           5.2.3. Client Authentication and Authorization ............59
                  5.2.3.1. Don't Issue Secrets to Clients with
                           Inappropriate Security Policy .............60
                  5.2.3.2. Require User Consent for Public
                           Clients without Secret ....................60
                  5.2.3.3. Issue a "client_id" Only in
                           Combination with "redirect_uri" ...........61
                  5.2.3.4. Issue Installation-Specific Client
                           Secrets ...................................61
                  5.2.3.5. Validate Pre-Registered "redirect_uri" ....62
                  5.2.3.6. Revoke Client Secrets .....................63
                  5.2.3.7. Use Strong Client Authentication
                           (e.g., client_assertion/client_token) .....63
           5.2.4. End-User Authorization .............................63
                  5.2.4.1. Automatic Processing of Repeated
                           Authorizations Requires Client Validation .63
                  5.2.4.2. Informed Decisions Based on Transparency ..63
                  5.2.4.3. Validation of Client Properties by
                           End User ..................................64
                  5.2.4.4. Binding of Authorization "code" to
                           "client_id" ...............................64
                  5.2.4.5. Binding of Authorization "code" to
                           "redirect_uri" ............................64
      5.3. Client App Security .......................................65
           5.3.1. Don't Store Credentials in Code or
                  Resources Bundled with Software Packages ...........65
           5.3.2. Use Standard Web Server Protection Measures
                  (for Config Files and Databases) ...................65
           5.3.3. Store Secrets in Secure Storage ....................65
           5.3.4. Utilize Device Lock to Prevent Unauthorized
                  Device Access ......................................66
           5.3.5. Link the "state" Parameter to User Agent Session ...66
      5.4. Resource Servers ..........................................66
           5.4.1. Authorization Headers ..............................66
           5.4.2. Authenticated Requests .............................67
           5.4.3. Signed Requests ....................................67
      5.5. A Word on User Interaction and User-Installed Apps ........68

Top      ToC       Page 6 
   6. Acknowledgements ...............................................69
   7. References .....................................................69
      7.1. Normative References ......................................69
      7.2. Informative References ....................................69

1.  Introduction

   This document gives additional security considerations for OAuth,
   beyond those in the OAuth specification, based on a comprehensive
   threat model for the OAuth 2.0 protocol [RFC6749].  It contains the
   following content:

   o  Documents any assumptions and scope considered when creating the
      threat model.

   o  Describes the security features built into the OAuth protocol and
      how they are intended to thwart attacks.

   o  Gives a comprehensive threat model for OAuth and describes the
      respective countermeasures to thwart those threats.

   Threats include any intentional attacks on OAuth tokens and resources
   protected by OAuth tokens, as well as security risks introduced if
   the proper security measures are not put in place.  Threats are
   structured along the lines of the protocol structure to help
   development teams implement each part of the protocol securely, for
   example, all threats for granting access, or all threats for a
   particular grant type, or all threats for protecting the resource
   server.

   Note: This document cannot assess the probability or the risk
   associated with a particular threat because those aspects strongly
   depend on the particular application and deployment OAuth is used to
   protect.  Similarly, impacts are given on a rather abstract level.
   But the information given here may serve as a foundation for
   deployment-specific threat models.  Implementors may refine and
   detail the abstract threat model in order to account for the specific
   properties of their deployment and to come up with a risk analysis.
   As this document is based on the base OAuth 2.0 specification, it
   does not consider proposed extensions such as client registration or
   discovery, many of which are still under discussion.

Top      ToC       Page 7 
2.  Overview

2.1.  Scope

   This security considerations document only considers clients bound to
   a particular deployment as supported by [RFC6749].  Such deployments
   have the following characteristics:

   o  Resource server URLs are static and well-known at development
      time; authorization server URLs can be static or discovered.

   o  Token scope values (e.g., applicable URLs and methods) are well-
      known at development time.

   o  Client registration is out of scope of the current core
      specification.  Therefore, this document assumes a broad variety
      of options, from static registration during development time to
      dynamic registration at runtime.

   The following are considered out of scope:

   o  Communication between the authorization server and resource
      server.

   o  Token formats.

   o  Except for the resource owner password credentials grant type (see
      [RFC6749], Section 4.3), the mechanism used by authorization
      servers to authenticate the user.

   o  Mechanism by which a user obtained an assertion and any resulting
      attacks mounted as a result of the assertion being false.

   o  Clients not bound to a specific deployment: An example could be a
      mail client with support for contact list access via the portable
      contacts API (see [Portable-Contacts]).  Such clients cannot be
      registered upfront with a particular deployment and should
      dynamically discover the URLs relevant for the OAuth protocol.

2.2.  Attack Assumptions

   The following assumptions relate to an attacker and resources
   available to an attacker.  It is assumed that:

   o  the attacker has full access to the network between the client and
      authorization servers and the client and the resource server,
      respectively.  The attacker may eavesdrop on any communications

Top      ToC       Page 8 
      between those parties.  He is not assumed to have access to
      communication between the authorization server and resource
      server.

   o  an attacker has unlimited resources to mount an attack.

   o  two of the three parties involved in the OAuth protocol may
      collude to mount an attack against the 3rd party.  For example,
      the client and authorization server may be under control of an
      attacker and collude to trick a user to gain access to resources.

2.3.  Architectural Assumptions

   This section documents assumptions about the features, limitations,
   and design options of the different entities of an OAuth deployment
   along with the security-sensitive data elements managed by those
   entities.  These assumptions are the foundation of the threat
   analysis.

   The OAuth protocol leaves deployments with a certain degree of
   freedom regarding how to implement and apply the standard.  The core
   specification defines the core concepts of an authorization server
   and a resource server.  Both servers can be implemented in the same
   server entity, or they may also be different entities.  The latter is
   typically the case for multi-service providers with a single
   authentication and authorization system and is more typical in
   middleware architectures.

2.3.1.  Authorization Servers

   The following data elements are stored or accessible on the
   authorization server:

   o  usernames and passwords

   o  client ids and secrets

   o  client-specific refresh tokens

   o  client-specific access tokens (in the case of handle-based design;
      see Section 3.1)

   o  HTTPS certificate/key

   o  per-authorization process (in the case of handle-based design;
      Section 3.1): "redirect_uri", "client_id", authorization "code"

Top      ToC       Page 9 
2.3.2.  Resource Server

   The following data elements are stored or accessible on the resource
   server:

   o  user data (out of scope)

   o  HTTPS certificate/key

   o  either authorization server credentials (handle-based design; see
      Section 3.1) or authorization server shared secret/public key
      (assertion-based design; see Section 3.1)

   o  access tokens (per request)

   It is assumed that a resource server has no knowledge of refresh
   tokens, user passwords, or client secrets.

2.3.3.  Client

   In OAuth, a client is an application making protected resource
   requests on behalf of the resource owner and with its authorization.
   There are different types of clients with different implementation
   and security characteristics, such as web, user-agent-based, and
   native applications.  A full definition of the different client types
   and profiles is given in [RFC6749], Section 2.1.

   The following data elements are stored or accessible on the client:

   o  client id (and client secret or corresponding client credential)

   o  one or more refresh tokens (persistent) and access tokens
      (transient) per end user or other security-context or delegation
      context

   o  trusted certification authority (CA) certificates (HTTPS)

   o  per-authorization process: "redirect_uri", authorization "code"

3.  Security Features

   These are some of the security features that have been built into the
   OAuth 2.0 protocol to mitigate attacks and security issues.

Top      ToC       Page 10 
3.1.  Tokens

   OAuth makes extensive use of many kinds of tokens (access tokens,
   refresh tokens, authorization "codes").  The information content of a
   token can be represented in two ways, as follows:

   Handle (or artifact)  A 'handle' is a reference to some internal data
      structure within the authorization server; the internal data
      structure contains the attributes of the token, such as user id
      (UID), scope, etc.  Handles enable simple revocation and do not
      require cryptographic mechanisms to protect token content from
      being modified.  On the other hand, handles require communication
      between the issuing and consuming entity (e.g., the authorization
      server and resource server) in order to validate the token and
      obtain token-bound data.  This communication might have a negative
      impact on performance and scalability if both entities reside on
      different systems.  Handles are therefore typically used if the
      issuing and consuming entity are the same.  A 'handle' token is
      often referred to as an 'opaque' token because the resource server
      does not need to be able to interpret the token directly; it
      simply uses the token.

   Assertion (aka self-contained token)  An assertion is a parseable
      token.  An assertion typically has a duration, has an audience,
      and is digitally signed in order to ensure data integrity and
      origin authentication.  It contains information about the user and
      the client.  Examples of assertion formats are Security Assertion
      Markup Language (SAML) assertions [OASIS.saml-core-2.0-os] and
      Kerberos tickets [RFC4120].  Assertions can typically be directly
      validated and used by a resource server without interactions with
      the authorization server.  This results in better performance and
      scalability in deployments where the issuing and consuming
      entities reside on different systems.  Implementing token
      revocation is more difficult with assertions than with handles.

   Tokens can be used in two ways to invoke requests on resource
   servers, as follows:

   bearer token  A 'bearer token' is a token that can be used by any
      client who has received the token (e.g., [RFC6750]).  Because mere
      possession is enough to use the token, it is important that
      communication between endpoints be secured to ensure that only
      authorized endpoints may capture the token.  The bearer token is
      convenient for client applications, as it does not require them to
      do anything to use them (such as a proof of identity).  Bearer
      tokens have similar characteristics to web single-sign-on (SSO)
      cookies used in browsers.

Top      ToC       Page 11 
   proof token  A 'proof token' is a token that can only be used by a
      specific client.  Each use of the token requires the client to
      perform some action that proves that it is the authorized user of
      the token.  Examples of this are MAC-type access tokens, which
      require the client to digitally sign the resource request with a
      secret corresponding to the particular token sent with the request
      (e.g., [OAuth-HTTP-MAC]).

3.1.1.  Scope

   A scope represents the access authorization associated with a
   particular token with respect to resource servers, resources, and
   methods on those resources.  Scopes are the OAuth way to explicitly
   manage the power associated with an access token.  A scope can be
   controlled by the authorization server and/or the end user in order
   to limit access to resources for OAuth clients that these parties
   deem less secure or trustworthy.  Optionally, the client can request
   the scope to apply to the token but only for a lesser scope than
   would otherwise be granted, e.g., to reduce the potential impact if
   this token is sent over non-secure channels.  A scope is typically
   complemented by a restriction on a token's lifetime.

3.1.2.  Limited Access Token Lifetime

   The protocol parameter "expires_in" allows an authorization server
   (based on its policies or on behalf of the end user) to limit the
   lifetime of an access token and to pass this information to the
   client.  This mechanism can be used to issue short-lived tokens to
   OAuth clients that the authorization server deems less secure, or
   where sending tokens over non-secure channels.

3.2.  Access Token

   An access token is used by a client to access a resource.  Access
   tokens typically have short life spans (minutes or hours) that cover
   typical session lifetimes.  An access token may be refreshed through
   the use of a refresh token.  The short lifespan of an access token,
   in combination with the usage of refresh tokens, enables the
   possibility of passive revocation of access authorization on the
   expiry of the current access token.

3.3.  Refresh Token

   A refresh token represents a long-lasting authorization of a certain
   client to access resources on behalf of a resource owner.  Such
   tokens are exchanged between the client and authorization server
   only.  Clients use this kind of token to obtain ("refresh") new
   access tokens used for resource server invocations.

Top      ToC       Page 12 
   A refresh token, coupled with a short access token lifetime, can be
   used to grant longer access to resources without involving end-user
   authorization.  This offers an advantage where resource servers and
   authorization servers are not the same entity, e.g., in a distributed
   environment, as the refresh token is always exchanged at the
   authorization server.  The authorization server can revoke the
   refresh token at any time, causing the granted access to be revoked
   once the current access token expires.  Because of this, a short
   access token lifetime is important if timely revocation is a high
   priority.

   The refresh token is also a secret bound to the client identifier and
   client instance that originally requested the authorization; the
   refresh token also represents the original resource owner grant.
   This is ensured by the authorization process as follows:

   1.  The resource owner and user agent safely deliver the
       authorization "code" to the client instance in the first place.

   2.  The client uses it immediately in secure transport-level
       communications to the authorization server and then securely
       stores the long-lived refresh token.

   3.  The client always uses the refresh token in secure transport-
       level communications to the authorization server to get an access
       token (and optionally roll over the refresh token).

   So, as long as the confidentiality of the particular token can be
   ensured by the client, a refresh token can also be used as an
   alternative means to authenticate the client instance itself.

3.4.  Authorization "code"

   An authorization "code" represents the intermediate result of a
   successful end-user authorization process and is used by the client
   to obtain access and refresh tokens.  Authorization "codes" are sent
   to the client's redirect URI instead of tokens for two purposes:

   1.  Browser-based flows expose protocol parameters to potential
       attackers via URI query parameters (HTTP referrer), the browser
       cache, or log file entries, and could be replayed.  In order to
       reduce this threat, short-lived authorization "codes" are passed
       instead of tokens and exchanged for tokens over a more secure
       direct connection between the client and the authorization
       server.

Top      ToC       Page 13 
   2.  It is much simpler to authenticate clients during the direct
       request between the client and the authorization server than in
       the context of the indirect authorization request.  The latter
       would require digital signatures.

3.5.  Redirect URI

   A redirect URI helps to detect malicious clients and prevents
   phishing attacks from clients attempting to trick the user into
   believing the phisher is the client.  The value of the actual
   redirect URI used in the authorization request has to be presented
   and is verified when an authorization "code" is exchanged for tokens.
   This helps to prevent attacks where the authorization "code" is
   revealed through redirectors and counterfeit web application clients.
   The authorization server should require public clients and
   confidential clients using the implicit grant type to pre-register
   their redirect URIs and validate against the registered redirect URI
   in the authorization request.

3.6.  "state" Parameter

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section 4.4.1.8)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

3.7.  Client Identifier

   Authentication protocols have typically not taken into account the
   identity of the software component acting on behalf of the end user.
   OAuth does this in order to increase the security level in delegated
   authorization scenarios and because the client will be able to act
   without the user being present.

   OAuth uses the client identifier to collate associated requests to
   the same originator, such as

   o  a particular end-user authorization process and the corresponding
      request on the token's endpoint to exchange the authorization
      "code" for tokens, or

Top      ToC       Page 14 
   o  the initial authorization and issuance of a token by an end user
      to a particular client, and subsequent requests by this client to
      obtain tokens without user consent (automatic processing of
      repeated authorizations)

   This identifier may also be used by the authorization server to
   display relevant registration information to a user when requesting
   consent for a scope requested by a particular client.  The client
   identifier may be used to limit the number of requests for a
   particular client or to charge the client per request.  It may
   furthermore be useful to differentiate access by different clients,
   e.g., in server log files.

   OAuth defines two client types, confidential and public, based on
   their ability to authenticate with the authorization server (i.e.,
   ability to maintain the confidentiality of their client credentials).
   Confidential clients are capable of maintaining the confidentiality
   of client credentials (i.e., a client secret associated with the
   client identifier) or capable of secure client authentication using
   other means, such as a client assertion (e.g., SAML) or key
   cryptography.  The latter is considered more secure.

   The authorization server should determine whether the client is
   capable of keeping its secret confidential or using secure
   authentication.  Alternatively, the end user can verify the identity
   of the client, e.g., by only installing trusted applications.  The
   redirect URI can be used to prevent the delivery of credentials to a
   counterfeit client after obtaining end-user authorization in some
   cases but can't be used to verify the client identifier.

   Clients can be categorized as follows based on the client type,
   profile (e.g., native vs. web application; see [RFC6749], Section 9),
   and deployment model:

   Deployment-independent "client_id" with pre-registered "redirect_uri"
      and without "client_secret"  Such an identifier is used by
      multiple installations of the same software package.  The
      identifier of such a client can only be validated with the help of
      the end-user.  This is a viable option for native applications in
      order to identify the client for the purpose of displaying meta
      information about the client to the user and to differentiate
      clients in log files.  Revocation of the rights associated with
      such a client identifier will affect ALL deployments of the
      respective software.

Top      ToC       Page 15 
   Deployment-independent "client_id" with pre-registered "redirect_uri"
      and with "client_secret"  This is an option for native
      applications only, since web applications would require different
      redirect URIs.  This category is not advisable because the client
      secret cannot be protected appropriately (see Section 4.1.1).  Due
      to its security weaknesses, such client identities have the same
      trust level as deployment-independent clients without secrets.
      Revocation will affect ALL deployments.

   Deployment-specific "client_id" with pre-registered "redirect_uri"
      and with "client_secret"  The client registration process ensures
      the validation of the client's properties, such as redirect URI,
      web site URL, web site name, and contacts.  Such a client
      identifier can be utilized for all relevant use cases cited above.
      This level can be achieved for web applications in combination
      with a manual or user-bound registration process.  Achieving this
      level for native applications is much more difficult.  Either the
      installation of the application is conducted by an administrator,
      who validates the client's authenticity, or the process from
      validating the application to the installation of the application
      on the device and the creation of the client credentials is
      controlled end-to-end by a single entity (e.g., application market
      provider).  Revocation will affect a single deployment only.

   Deployment-specific "client_id" with "client_secret" without
      validated properties  Such a client can be recognized by the
      authorization server in transactions with subsequent requests
      (e.g., authorization and token issuance, refresh token issuance,
      and access token refreshment).  The authorization server cannot
      assure any property of the client to end users.  Automatic
      processing of re-authorizations could be allowed as well.  Such
      client credentials can be generated automatically without any
      validation of client properties, which makes it another option,
      especially for native applications.  Revocation will affect a
      single deployment only.



(page 15 continued on part 2)

Next RFC Part