INTERNET-DRAFT N. Sakimura Intended Status: Proposed Standard NRI Expires: August 22, 2013 B. Kihara, Ed Lepidum February 18, 2013 OpenID Connect Extension for Password-Based Non-Web Protocols draft-sakimura-oidc-extension-nonweb-00 Abstract This specification describes extensions to OpenID Connect that defines how OpenID Providers issue credentials for client applications and how client applications and relying parties handle the credentials, typically over protocols that use passwords for authentication without changing existing client applications. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 Sakimura, et al. Expires August 22, 2013 [Page 1] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Auth Scope Values . . . . . . . . . . . . . . . . . . . . 4 2.2. Auth UserInfo Response . . . . . . . . . . . . . . . . . . 5 3. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Access Token Issue . . . . . . . . . . . . . . . . . . . . 6 3.2. Access Token Usage . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Access Token Revocation . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Integration with Traditional Services . . . . . . . . 9 Appendix B. Document History . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Sakimura, et al. Expires August 22, 2013 [Page 2] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 1. Introduction Protocols such as IMAP ([RFC3501]) and SMTP ([RFC5321]) use passwords for authentication, and thus end-users are threatened by problems of passwords. End-users tend to use weak passwords, to leak passwords, and to carry same passwords to multiple service providers. To resolve the problem, the Simple Authentication and Security Layer (SASL) ([RFC4422]) and non-password authentication protocols over SASL are introduced. However, these protocols require upgrading client applications and this discourages these protocols from becoming widespread. This document describes extensions to OpenID Connect ([OIDF.Connect.Messages]) that allows OpenID Providers to provide tokens used as credentials for client applications that do not support token handling defined in protocols such as OAuth ([RFC6749]). Besides, this document explains how OpenID Providers and relying parties validate tokens that are passed instead of passwords. By the extension, advantages of token-based authentication and authorization are introduced to protocols that use passwords; for example, when an end-user loses his/her smartphone, he/she can revoke the token put in the smartphone without resetting other client software instances. [TODO: protocol abstract here?] 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Sakimura, et al. Expires August 22, 2013 [Page 3] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 2. Messages Most client applications for protocols such as IMAP ([RFC3501]) and SMTP ([RFC5321]) do not support token handling in OAuth ([RFC6749]) or other frameworks; they cannot request authorization, cannot receive authorization code, and cannot request access tokens. To resolve this problem, service providers can provide end-users with web pages that handle tokens and instruct end-users to copy access tokens from the page to the password box on the client application. However, client applications cannot refresh access tokens; for usability reasons, long-lived access tokens are wanted. Moreover, OpenID Providers might have to handle such access tokens specially. In order to support authentication and authorization by using access tokens as credentials, new scope values and behaviors are introduced to the OpenID Connect specifications ([OIDF.Connect.Messages]). 2.1. Auth Scope Values This specification defines the auth scope values. The auth scope values are scope values which start with "auth_" and indicate that the client wants an access token as a credential for client application authentication and authorization. When the OpenID Provider received auth scope values in an authorization request, the OpenID Provider MUST provide Bearer type access tokens and is expected to issue a long-lived access token which can be revoked. If auth scope values are specified in an authorization request, the client SHOULD NOT request other unnecessary scopes, because the issued access token will be long-lived and transferred in uncertain ways. It is RECOMMENDED to use auth scope values only with the openid scope. The OpenID Provider SHOULD deny requests with auth scope values when scopes other than openid scope is specified. The following is a non-normative example of a scope Request using an auth scope. scope=openid auth_imap [[Note: the name of the scope values are unsettled. One implementation uses a PAM module to validate tokens in protocols such as IMAP and SMTP, so values like pam_imap and pam_smtp should be also suitable.]] [[Note: if using OpenID Connect, we can use OpenID Request Object instead of/ together with scopes. For example, "auth" scope indicates Sakimura, et al. Expires August 22, 2013 [Page 4] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 that the required access token is used as a credential, and precise control of authorization (protocol names, control in the protocol, etc.) are represented in other ways.]] 2.2. Auth UserInfo Response When the client requests UserInfo with the access token issued in response to auth scope values, the OpenID Provider returns claims for the auth scope values. The name of the claim is the same as the scope value, and the value of the claim is a JSON object ([RFC4627]). The members of the JSON object are undefined and reserved for future use. The following is a non-normative example of a UserInfo Response for an auth scope. { "sub": "fb5e4c66b91e929171f6d31b984447a3", "auth_imap": {} } [[Note: the current draft is based on OpenID Connect. However, using OAuth Token Introspection draft (draft-richer-oauth-introspection), this protocol might become independent of OpenID Connect.]] Sakimura, et al. Expires August 22, 2013 [Page 5] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 3. Protocol Flows In this section, the protocol flows using auth scope values and auth UserInfo response are described. 3.1. Access Token Issue To obtain an access token for client application authentication and authorization, the service provider, the OpenID Provider, and the end-user will act as follows: 1. The end-user accesses the web page of the service provider in order to obtain information to use a client application, and selects an OpenID Provider. 2. The service provider sends an authorization request to the OpenID Provider with auth scope values. 3. The OpenID Provider asks the end-user whether he/she wants to authorize the request. It is RECOMMENDED for the OpenID Provider to provide the end-user with methods to distinguish access tokens in order to revoke the intended access token if necessary. 4. The service provider receives an authorization response and obtains a Bearer type access token. 5. The service provider receives the sub claim from the OpenID Provider by using the access token or by decoding ID token if exists, and links the OpenID Provider, the sub claim, and the local account that the service provider manages. 6. The service provider shows the access token to the end-user and instruct to copy the access token to the password box on the client application. 3.2. Access Token Usage The access token obtained by the above process is used as a credential in the protocol that normally uses a password such as IMAP ([RFC3501]). When the service provider receives an access token, the service provider authenticates the end-user in the following way. 1. The service provider sends UserInfo request to the OpenID Provider with the access token. 2. The OpenID Provider returns UserInfo response described in the section 2.2. 3. The service provider checks whether the there is the claim name that the service provider requires. 4. The service provider checks whether the sub claim is the same as the value that was obtained in the access token issue flow. Sakimura, et al. Expires August 22, 2013 [Page 6] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 After authenticating the end-user, the service provider responds to the client application and provides services defined in the protocol. The following is a non-normative example of access token usage in IMAP. C: a001 LOGIN alice eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJpc3M... [Here, the service provider validates the token.] S: a001 OK LOGIN completed 3.2.1. Access Token Revocation [TODO: revoking access tokens] Sakimura, et al. Expires August 22, 2013 [Page 7] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 4. Security Considerations 5. IANA Considerations 6. References 6.1. Normative References [OIDF.Connect.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0 - draft 15", January 2013, . [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", draft-ietf-oauth-json- web-token (work in progress), December 2012. [I-D.richer-oauth-introspection] J. Richer, "OAuth Token Introspection", draft-richer-oauth-introspection (work in progress), February 2013. 6.2. Informative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. Sakimura, et al. Expires August 22, 2013 [Page 8] INTERNET DRAFT OIDC Extension for Non-Web Protocols February 2013 Appendix A. Integration with Traditional Services [TODO: Method to adopt this protocol with traditional password login] Appendix B. Document History -00 o Initial draft. Authors' Addresses Nat Sakimura Nomura Research Institute EMail: n-sakimura@nri.co.jp Boku Kihara (editor) Lepidum Co. Ltd. EMail: kihara@lepidum.co.jp Sakimura, et al. Expires August 22, 2013 [Page 9]