Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6819

OAuth 2.0 Threat Model and Security Considerations

Pages: 71
Informational
Errata
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC6819 - 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   ToC   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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   RFC6819 - 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 Section