RESTful Authentication for OpenID

8/13/2019 RESTful Authentication for OpenID

1/9

RESTful Authentication OpenID

Sandhana @ CSE 2011 Page 1

RESTful Authentication for OpenID

Abstract

OpenID is an open and decentralized authentication and identity system. OpenID

relying parties do not manage end user credentials such as passwords or any other

sensitive information which makes authentication and identity management much

simpler and secure.

OpenID specifications do not discuss how users are authenticated to the OpenID

providers. However, this specification defines an authentication mechanism that can

be used by web services clients to authenticate themselves to OpenID providers.

OpenID protocol involves two web browser redirections at authentication: redirection

from the relying party to the OpenID provider with an Authentication Request

message and a redirection from the OpenID Provider to the relying party with an

Authentication Response message. The authentication mechanism defined in this

specification, eliminates two redirections mentioned above so that web service

clients can directly communicate with OpenID providers and perform authentications.

Table of Contents

Abstract .............................................................................................. 1Requirements Notation and Conventions ....................................................... 2Terminology ......................................................................................... 2Introduction ......................................................................................... 3Protocol Overview .................................................................................. 3Normalization and Discovery ..................................................................... 4Requesting Authentication ........................................................................ 5

Direct Communication .......................................................................... 5


2/9



Request Parameters .......................................................................... 5

SampleRequest ................................................................................ 6

Responding to Authentication Requests ........................................................ 6Positive Assertion ................................................................................ 6

Sample Positive Response ................................................................... 7

Negative Assertions ........................................................................... 7

Verifying response with OP ....................................................................... 8Request Parameters ............................................................................. 8

Sample Verification Request ................................................................ 8

Response Parameters ........................................................................... 8Sample Response .............................................................................. 8

Security Considerations ........................................................................... 9

Requirements Notation and Conventions

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].

Throughout this document, values are quoted to indicate that they are to be taken

literally. When using these values in protocol messages, the quotes MUST NOT be used

as part of the value.

Terminology

OpenID Provider:OP. An OpenID Authentication server on which a Relying Party relies

for an assertion that the end user controls an Identifier.

OP Endpoint:The URL which accepts OpenID Authentication protocol messages,

obtained by performing discovery on the User-Supplied Identifier. This value MUST be

an absolute HTTP or HTTPS URL.


3/9



OP Identifier:An Identifier for an OpenID Provider.

Introduction

This specification defines an authentication mechanism for the OpenID protocol that

can be used by web service clients to authenticate users to OpenID provides by direct

communication in a RESTful manner.

This specification is a supporting specification for the OpenIDToken Profile for Web

Servicesspecification. OpenIDTokenProfile provides a mechanism that can be used by

web services systems to utilize OpenID protocol decentralized authentication.

Existing OpenID protocol contains two browser redirections which are used toauthenticate users to and get responses from, the OpenID provider. Therefore the

existing OpenID protocol heavily depends on web browser redirection (Indirect

Communication) in the process of authentication. Nevertheless in most web services

systems getting web browser involvement for communications is inappropriate.

Therefore web service systems require a browser free mechanism for OpenID

authentication. The authentication mechanism discuss in this specification addresses

this issue.

Protocol Overview

1. Web Service client initialize the authentication with OpenID identifier. Itperforms discovery on the normalized OpenID and establish the OP endpoint

URL that client uses for authentication.

2. Web service client sends an Authentication request to the end point URL withthe password.

3. The OpenID Provider extracts the password from the request and performs userauthentication.


4/9



4. The OP send back a positive response with required attributes if theauthentication was successful, else OP send back negative response.

5. Web service client receives the positive response and creates the request foraccess web service.

6. Web service receives the request and processes the request; verify the requestwith the OP. if verification success web server grants the request to access web

service.

Normalization and Discovery

Normalization and discovery are done according to the OpenID Authentication 2.0specification. Yadis discovery is used as the discovery protocol.

Figure 1 - OpenID protocol overview

1. Normalizing andperform

discovery

2. Send Authentication

re uest

3. Validate

Authentication re uest

4. Send positive or

ne ative res onse.

5. Request access for web

service with O enID

6. Validate the

request

7. Accept or deny access to

web service

Client

OP

IP


5/9



Requesting Authentication

Direct Communication

Direct communication is initiated by a web service client to an OP endpoint URL.

This specification extends the Authentication Request message such that it carriesusers password that is used to authenticate to the OpenID provider. This

communication MUST be done over HTTPS.

Request Parameters

openid.nsValue: "http://specs.openid.net/auth/2.0"

This particular value MUST be present for the request to be a valid

OpenID Authentication 2.0 request

openid.passwordValue: Password to log in to the OP.

openid.modeValue: checkid_setup or checked_immediate

This parameter specifies that the request is an authentication request

message.

openid.claimed_idValue: The claimed Identifier.

openid.identityValue: the OP-Local Identifier.


6/9



SampleRequest

Responding to Authentication Requests

OpenID Provider must use the plain text password in the Authentication Request

message to perform authentication on the supplied user supplied identifier. Upon the

completion of the authentication OP should create a Authentication Response

message as defined in the OpenID authentication 2.0 specifications.

Positive Assertion

Positive assertions are direct responses with following fields.

openid.nsValue: "http://specs.openid.net/auth/2.0"

This particular value MUST be present for the request to be a valid

OpenID Authentication 2.0 request.

openid.modeValue: id_res.

openid.claimed_idValue: (optional) The Claimed Identifier. "openid.claimed_id" and

"openid.identity" SHALL be either both present or both absent.

openid.identityValue: The OP-Local Identifier.


7/9



openid.response_nonceValue: a String 255 characters or less in length.that MUST be unique to

this particular successful authentication response. The nonce MUST start

with the current time on the server (According to the OpenID

Authentication 2.0).

openid.assoc_handleValue: The handle for the association that was used to sign this

assertion.

openid.signedValue: Comma-separated list of signed fields.

openid.sigValue: Base 64 encoded signature.

Sample Positive Response

Negative Assertions

If the OP is unable to verify the identity of the client, OP responds with the negativeassertion to the web service client. (According to the OpenID Authentication 2.0)


8/9



Verifying response with OP

In scenario of web service authentication using OpenID, initiation of the request is

done by the client and the verification is done in the server side. So the transactions

are done in the stateless mode. In the stateless mode the signature verification

performed by the OP, the web server sends the direct request to the OP. To verify the

signature, the OP uses a private association that was generated when it issued the

positive assertion.

Request Parameters

Exact copy of authentication response is sent, except openid.mode.

openid_modeValue: check_authentication

Sample Verification Request

Response Parameters

is_validValue: true is verification succeeding, false if verification fails.

Sample Response


9/9



Security Considerations

This specification does not violate any of the security requirements defined in the

OpenID specification 2.0. Nevertheless this specification enforces direct

communication between the OpenID Provider and the Web Service Client to be over

HTTPS. One major reason is that since the Authentication Request message carries

the user password, there is a risk of exposing user password. This can be prevented by

communicating the Authentication Request message over HTTPS.

Documents

RESTful Authentication for OpenID