draft-ietf-oauth-spop-00.txt   draft-ietf-oauth-spop-01.txt 
OAuth Working Group N. Sakimura, Ed. OAuth Working Group N. Sakimura, Ed.
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: February 26, 2015 Independent Expires: April 29, 2015 Ping Identity
N. Agarwal N. Agarwal
Google Google
August 25, 2014 October 26, 2014
Symmetric Proof of Possession for the OAuth Authorization Code Grant Symmetric Proof of Possession for the OAuth Authorization Code Grant
draft-ietf-oauth-spop-00 draft-ietf-oauth-spop-01
Abstract Abstract
The OAuth 2.0 public client utilizing authorization code grant is The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
susceptible to the code interception attack. This specification 6749 - 4.1) is susceptible to the code interception attack. This
describe a mechanism that acts as a control against this threat. specification describes a mechanism that acts as a control against
this threat.
Requirements Language
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 RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 26, 2015. This Internet-Draft will expire on April 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
2.1. code verifier . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. code challenge . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Client creates a code verifier . . . . . . . . . . . . . 4
3.1. Client checks the server support . . . . . . . . . . . . 3 4.2. Client creates the code challenge . . . . . . . . . . . . 4
3.2. (optional) Client registers its desired code challenge 4.3. Client sends the code challenge with the authorization
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4 request . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Client creates a code verifier . . . . . . . . . . . . . 4 4.4. Server returns the code . . . . . . . . . . . . . . . . . 5
3.4. Client sends the code challenge with the authorization 4.5. Client sends the code and the secret to the token
request . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Server returns the code . . . . . . . . . . . . . . . . . 4
3.6. Client sends the code and the secret to the token
endpoint . . . . . . . . . . . . . . . . . . . . . . . . 5 endpoint . . . . . . . . . . . . . . . . . . . . . . . . 5
3.7. Server verifies code_verifier before returning the tokens 5 4.6. Server verifies code_verifier before returning the tokens 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Revision History . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Entropy of the code verifier . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Protection against eavesdroppers . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.3. Chekcing the Server support . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 7.4. OAuth security considerations . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Revision History . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Public clients in OAuth 2.0 [RFC6749] is susceptible to the "code" Public clients in OAuth 2.0 [RFC6749] are susceptible to the
interception attack. The "code" interception attack is an attack authorization "code" interception attack. A malicious client
that a malicious client intercepts the "code" returned from the intercepts the authorization code returned from the authorization
authorization endpoint and uses it to obtain the access token. This endpoint and uses it to obtain the access token. This is possible on
is possible on a public client as there is no client secret a public client as there is no client secret associated for it to be
associated for it to be sent to the token endpoint. This is sent to the token endpoint. This is especially true on Smartphone
especially true on some smartphone platform in which the "code" is applications where the authorization code can be returned through
returned to a redirect URI with a custom scheme as there can be custom URL Schemes where the same scheme can be registered by
multiple apps that can register the same scheme.Under this scenario, multiple applications. Under this scenario, the mitigation strategy
the mitigation strategy stated in section 4.4.1 of [RFC6819] does not stated in section 4.4.1 of [RFC6819] does not work as they rely on
work as they rely on per-client instance secret or per client per-client instance secret or per client instance redirect URI.
instance redirect uri.
To mitigate this attack, this extension utilizes dynamically created To mitigate this attack, this extension utilizes a dynamically
cryptographically random key called 'code verifier'. The code created cryptographically random key called 'code verifier'. The
verifier is created for every authorization request and its code verifier is created for every authorization request and its
transformed value called code challenge is sent to the authorization transformed value, called 'code challenge', is sent to the
server to obtain the authorization code. The "code" obtained is then authorization server to obtain the authorization code. The
sent to the token endpoint with the code verifier and the server authorization "code" obtained is then sent to the token endpoint with
compares it with the previously received request code so that it can the 'code verifier' and the server compares it with the previously
perform the proof of possession of the code verifier by the client. received request code so that it can perform the proof of possession
This works as the mitigation since the attacker would not know the of the 'code verifier' by the client. This works as the mitigation
one-time key. since the attacker would not know this one-time key.
2. Terminology 2. Notational Conventions
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 Key
words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
these words are used without being spelled in uppercase then they are
to be interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 3producing a [USASCII] STRING.
BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING,
per Section 3, producing a UTF-8 sequence of octets.
SHA256(STRING) denotes a SHA2 256bit hash [RFC4634] of STRING.
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
of STRING.
ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING.
The concatenation of two values A and B is denoted as A || B.
3. Terminology
In addition to the terms defined in OAuth 2.0 [RFC6749], this In addition to the terms defined in OAuth 2.0 [RFC6749], this
specification defines the following terms. specification defines the following terms:
2.1. code verifier code verifier A cryptographically random string that is used to
correlate the authorization request to the token request.
cryptographically random string with big enough entropy that is used code challenge A challenge derived from the code verifier that is
to correlate the authorization request to the token request sent in the authorization request, to be verified against later.
2.2. code challenge Base64url Encoding Base64 encoding using the URL- and filename-safe
character set defined in Section 5 of RFC 4648 [RFC4648], with all
trailing '=' characters omitted (as permitted by Section 3.2) and
without the inclusion of any line breaks, white space, or other
additional characters. (See Appendix A for notes on implementing
base64url encoding without padding.)
either the code verifier itself or some transformation of it that is 4. Protocol
sent from the client to the server in the authorization request
NOTE 1: The client and the server MAY use mutually agreed pre- 4.1. Client creates a code verifier
negotiated algorithm such as base64url encoding of the left most
128bit of SHA256 hash.
NOTE 2: If no algorithm has been negotiated, it is treated as the The client first creates a code verifier, "code_verifier", for each
code verifier itself. OAuth 2.0 [RFC6749] Authorization Request, in the following manner:
3. Protocol code_verifier = high entropy cryptographic random [USASCII] sequence
using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / "-"
/ "_" from Sec 5 of RFC 4648 [RFC4648] , with length less than 128
characters.
3.1. Client checks the server support ABNF for "code_verifier" is as follows.
Before starting the authorization process, the client MUST make sure code_verifier = 42*128unreserved
that the server supports this specification. It may be obtained out- unreserved = [A-Z] / [a-z] / [0-9] / "-" / "_"
of-band or through some other mechanisms such as the discovery
document in OpenID Connect Discovery [OpenID.Discovery]. The exact
mechanism on how the client obtains this information is out of scope
of this specification.
The client that wishes to use this specification MUST stop proceeding NOTE: code verifier SHOULD have enough entropy to make it impractical
if the server does not support this extension. to guess the value. It is RECOMMENDED that the output of a suitable
random number generator be used to create a 32-octet sequence. The
Octet sequence is then BASE64URL encoded to produce a 42-octet URL
safe string to use as the code verifier.
3.2. (optional) Client registers its desired code challenge algorithm 4.2. Client creates the code challenge
In this specification, the client sends the transformation of the The client then creates a code challenge, "code_challenge", derived
code verifier to the authorization server in the front channel. The from the "code_verifier". The code challenge can use one of two
default transformation is not doing transformation at all. If the transformations on the "code_verifier".
the server supports, the client MAY register its desired
transformation algorithm to the server. If the algorithm is
registered, the server MUST reject any request that does not conform
to the algorithm.
How does this client registers the algorithm is out of scope for this plain "code_challenge" = "code_verifier"
specification.
Also, this specification does not define any transformation other S256 "code_challenge" = BASE64URL(SHA256("code_verifier"))
than the default transformation.
3.3. Client creates a code verifier It is RECOMMENDED to use the S256 [RFC4634] transformation when
possible.
The client then creates a code verifier, "code_verifier", in the ABNF for "code_challenge" is as follows.
following manner.
code_verifier = high entropy cryptographic random string of length code_challenge = 42*128unreserved
less than 128 bytes unreserved = [A-Z] / [a-z] / [0-9] / "-" / "_"
NOTE: code verifier MUST have high enough entropy to make it 4.3. Client sends the code challenge with the authorization request
inpractical to guess the value.
3.4. Client sends the code challenge with the authorization request The client sends the code challenge as part of the OAuth 2.0
[RFC6749] Authorization Request (Section 4.1.1.) using the following
additional parameters:
Then, the client creates a code challenge, "code_challenge", by code_challenge REQUIRED. Code challenge.
applying the pre-negotiated algorithm between the client and the
server. The default behaviour is no transformation, i.e.,
"code_challenge" == "code_verifier". The authorization server MUST
support this 'no transformation' algorithm.
The client sends the code challenge with the following parameter with code_challenge_method OPTIONAL, defaults to "plain". Code verifier
the OAuth 2.0 [RFC6749] Authorization Request: transformation method, "S256" or "plain".
code_challenge REQUIRED. code challenge. 4.4. Server returns the code
3.5. Server returns the code When the server issues the "code" in the Authorization Response, it
MUST associate the "code_challenge" and "code_challenge_method"
values with the "code" so it can be verified later.
When the server issues a "code", it MUST associate the Typically, the "code_challenge" and "code_challenge_method" values
"code_challenge" value with the "code" so that it can be used later. are stored in encrypted form in the "code" itself, but it could as
well be just stored at the server, associated with the code. The
server MUST NOT include the "code_challenge" value in the form that
other entities can extract.
Typically, the "code_challenge" value is stored in encrypted form in The exact method that the server uses to associate the
the "code", but it could as well be just stored in the server in "code_challenge" with the issued "code" is out of scope for this
association with the code. The server MUST NOT include the specification.
"code_challenge" value in the form that any entity but itself can
extract it.
3.6. Client sends the code and the secret to the token endpoint 4.5. Client sends the code and the secret to the token endpoint
Upon receipt of the "code", the client sends the request to the token Upon receipt of the "code", the client sends the Access Token Request
endpoint. In addition to the parameters defined in OAuth 2.0 to the token endpoint. In addition to the parameters defined in
[RFC6749], it sends the following parameter: OAuth 2.0 [RFC6749] Access Token Request (Section 4.1.3.), it sends
the following parameter:
code_verifier REQUIRED. code verifier code_verifier REQUIRED. Code verifier
3.7. Server verifies code_verifier before returning the tokens 4.6. Server verifies code_verifier before returning the tokens
Upon receipt of the request at the token endpoint, the server Upon receipt of the request at the Access Token endpoint, the server
verifies it by calculating the code challenge from "code_verifier" verifies it by calculating the code challenge from received
value and comparing it with the previously associated "code_verifier" and comparing it with the previously associated
"code_challenge". If they are equal, then the successful response "code_challenge", after first transforming it according to the
SHOULD be returned. If the values are not equal, an error response "code_challenge_method" method specified by the client.
indicating "invalid_grant" as described in section 5.2 of OAuth 2.0
[RFC6749] SHOULD be returned.
4. IANA Considerations If the "code_challenge_method" from 3.2 was "S256", the received
"code_verifier" is first hashed with SHA-256 then compared to the
base64url decoded "code_challenge". i.e.,
SHA256("code_verifier" ) == BASE64URL-DECODE("code_challenge").
If the "code_challenge_method" from 3.2 was "none", they are compared
directly. i.e.,
"code_challenge" == "code_verifier".
If the values are equal, the Access Token endpoint MUST continue
processing as normal (as defined by OAuth 2.0 [RFC6749]). If the
values are not equal, an error response indicating "invalid_grant" as
described in section 5.2 of OAuth 2.0 [RFC6749] MUST be returned.
5. Compatibility
Server implementations of this specification MAY accept OAuth2.0
Clients that do not implement this extension. If the "code_verifier"
is not received from the client in the Authorization Request, servers
supporting backwards compatibility SHOULD revert to a normal OAuth
2.0 [RFC6749] protocol.
As the OAuth 2.0 [RFC6749] server responses are unchanged by this
specification, client implementations of this specification do not
need to know if the server has implemented this specification or not,
and SHOULD send the additional parameters as defined in Section 3. to
all servers.
6. IANA Considerations
This specification makes a registration request as follows: This specification makes a registration request as follows:
4.1. OAuth Parameters Registry 6.1. OAuth Parameters Registry
This specification registers the following parameters in the IANA This specification registers the following parameters in the IANA
OAuth Parameters registry defined in OAuth 2.0 [RFC6749]. OAuth Parameters registry defined in OAuth 2.0 [RFC6749].
o Parameter name: code_verifier o Parameter name: code_verifier
o Parameter usage location: Access Token Request o Parameter usage location: Access Token Request
o Change controller: OpenID Foundation Artifact Binding Working o Change controller: IESG
Group - openid-specs-ab@lists.openid.net
o Specification document(s): this document o Specification document(s): this document
o Related information: None
o Parameter name: code_challenge o Parameter name: code_challenge
o Parameter usage location: Authorization Request o Parameter usage location: Authorization Request
o Change controller: OpenID Foundation Artifact Binding Working
Group - openid-specs-ab@lists.openid.net
o Change controller: IESG
o Specification document(s): this document o Specification document(s): this document
o Related information: None o Parameter name: code_challenge_method
5. Security Considerations o Parameter usage location: Authorization Request
o Change controller: IESG
o Specification document(s): this document
7. Security Considerations
7.1. Entropy of the code verifier
The security model relies on the fact that the code verifier is not The security model relies on the fact that the code verifier is not
learned or guessed by the attacker. It is vitally important to learned or guessed by the attacker. It is vitally important to
adhere to this principle. As such, the code verifier has to be adhere to this principle. As such, the code verifier has to be
created in such a manner that it is cryptographically random and has created in such a manner that it is cryptographically random and has
high entropy that it is not practical for the attacker to guess, and high entropy that it is not practical for the attacker to guess. It
if it is to be returned inside "code", it has to be encrypted in such is RECOMMENDED that the output of a suitable random number generator
a manner that only the server can decrypt and extract it. be used to create a 32-octet sequence.
If the no transformation algorithm, which is the default algorithm, 7.2. Protection against eavesdroppers
is used, the client MUST make sure that the request channel is
adequately protected. On a platform that it is not possible, the Unless there is a compelling reason, implementations SHOULD use
client and the server SHOULD utilize a transformation algorithm that "S256" method to protect against eavesdroppers intercepting the
makes it reasonably hard to recalculate the code verifier from the "code_challenge". If the no transformation algorithm, which is the
code challenge. default algorithm, is used, the client SHOULD make sure that the
authorization request is adequately protected from an eavesdropper.
If "code_challenge" is to be returned inside authorization "code", it
has to be encrypted in such a manner that only the server can decrypt
and extract it.
7.3. Chekcing the Server support
Before starting the authorization process, the client SHOULD make
sure that the server supports this specification. Confirmation of
the server support may be obtained out-of-band or through some other
mechanisms such as the discovery document in OpenID Connect Discovery
[OpenID.Discovery]. The exact mechanism on how the client obtains
this information is out of scope of this specification.
7.4. OAuth security considerations
All the OAuth security analysis presented in [RFC6819] applies so All the OAuth security analysis presented in [RFC6819] applies so
readers SHOULD carefully follow it. readers SHOULD carefully follow it.
6. Acknowledgements 8. Acknowledgements
The initial draft of this specification was created by the OpenID AB/ The initial draft of this specification was created by the OpenID AB/
Connect Working Group of the OpenID Foundation, by most notably of Connect Working Group of the OpenID Foundation, by most notably of
the following people: the following people:
o Naveen Agarwal, Google o Naveen Agarwal, Google
o Dirk Balfanz, Google o Dirk Balfanz, Google
o Sergey Beryozkin o Sergey Beryozkin
o John Bradley, Ping Identity o John Bradley, Ping Identity
o Brian Campbell, Ping Identity o Brian Campbell, Ping Identity
o William Denniss, Google
o Eduardo Gueiros, Jive Communications
o Phil Hunt, Oracle o Phil Hunt, Oracle
o Ryo Ito, mixi o Ryo Ito, mixi
o Michael B. Jones, Microsoft o Michael B. Jones, Microsoft
o Torsten Lodderstedt, Deutsche Telekom o Torsten Lodderstedt, Deutsche Telekom
o Breno de Madeiros, Google o Breno de Medeiros, Google
o Prateek Mishra, Oracle o Prateek Mishra, Oracle
o Anthony Nadalin, Microsoft o Anthony Nadalin, Microsoft
o Axel Nenker, Deutsche Telekom o Axel Nenker, Deutsche Telekom
o Nat Sakimura, Nomura Research Institute o Nat Sakimura, Nomura Research Institute
7. Revision History 9. Revision History
-01
o Specified exactly two supported transformations
o Moved discovery steps to security considerations.
o Incorporated readability comments by Eduardo Gueiros.
o Changed MUST in 3.1 to SHOULD.
-00 -00
o Initial version. o Initial IETF version.
8. References 10. References
8.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [USASCII] American National Standards Institute, "Coded Character
Threat Model and Security Considerations", RFC 6819, Set -- 7-bit American Standard Code for Information
January 2013. Interchange", ANSI X3.4, 1986.
8.2. Informative References 10.2. Informative References
[OpenID.Discovery] [OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", February 2014. Connect Discovery 1.0", February 2014.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007. 4949, August 2007.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
January 2013.
Appendix A. Notes on implementing base64url encoding without padding
This appendix describes how to implement base64url encoding and
decoding functions without padding based upon standard base64
encoding and decoding functions that do use padding.
To be concrete, example C# code implementing these functions is shown
below. Similar code could be used in other languages.
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 62nd char of encoding
s = s.Replace('_', '/'); // 63rd char of encoding
switch (s.Length % 4) // Pad with trailing '='s
{
case 0: break; // No pad chars in this case
case 2: s += "=="; break; // Two pad chars
case 3: s += "="; break; // One pad char
default: throw new System.Exception(
"Illegal base64url string!");
}
return Convert.FromBase64String(s); // Standard base64 decoder
}
As per the example code above, the number of '=' padding characters
that needs to be added to the end of a base64url encoded string
without padding to turn it into one with padding is a deterministic
function of the length of the encoded string. Specifically, if the
length mod 4 is 0, no padding is added; if the length mod 4 is 2, two
'=' padding characters are added; if the length mod 4 is 3, one '='
padding character is added; if the length mod 4 is 1, the input is
malformed.
An example correspondence between unencoded and encoded values
follows. The octet sequence below encodes into the string below,
which when decoded, reproduces the octet sequence.
3 236 255 224 193
A-z_4ME
Authors' Addresses Authors' Addresses
Nat Sakimura (editor) Nat Sakimura (editor)
Nomura Research Institute Nomura Research Institute
1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg.
Chiyoda-ku, Tokyo 100-0005 Chiyoda-ku, Tokyo 100-0005
Japan Japan
Phone: +81-3-5533-2111 Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/ URI: http://nat.sakimura.org/
skipping to change at page 8, line 15 skipping to change at page 11, line 18
Nomura Research Institute Nomura Research Institute
1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg.
Chiyoda-ku, Tokyo 100-0005 Chiyoda-ku, Tokyo 100-0005
Japan Japan
Phone: +81-3-5533-2111 Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/ URI: http://nat.sakimura.org/
John Bradley John Bradley
Independent Ping Identity
Casilla 177, Sucursal Talagante Casilla 177, Sucursal Talagante
Talagante, RM Talagante, RM
Chile Chile
Phone: +44 20 8133 3718 Phone: +44 20 8133 3718
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
Naveen Agarwal Naveen Agarwal
Google Google
 End of changes. 65 change blocks. 
159 lines changed or deleted 308 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/