Difference between revisions of "CLARIN/OAuth2"

From PDP/Grid Wiki
Jump to navigationJump to search
(→‎Documents: add dailymile details)
(→‎Documents: add viadeo detail)
Line 34: Line 34:
 
** Pinterest (see [http://www.programmableweb.com/api/pinterest here], [https://github.com/kellan/pinterest.api.php here] and [http://tijn.bo.lt/pinterest-api here]) code flow
 
** Pinterest (see [http://www.programmableweb.com/api/pinterest here], [https://github.com/kellan/pinterest.api.php here] and [http://tijn.bo.lt/pinterest-api here]) code flow
 
** Yapp
 
** Yapp
−
** [http://dev.viadeo.com/documentation/authentication/oauth-authentication/ Viadeo]
+
** [http://dev.viadeo.com/documentation/authentication/oauth-authentication/ Viadeo] code+implicit flow
 
** [http://www.dailymotion.com/doc/api/authentication.html Dailymotion] [http://www.flatws.cn/article/program/ruby/2011-04-04/19319.html draft 10] code+implicit+owner  
 
** [http://www.dailymotion.com/doc/api/authentication.html Dailymotion] [http://www.flatws.cn/article/program/ruby/2011-04-04/19319.html draft 10] code+implicit+owner  
 
** [https://www.x.com/developers/x.commerce/products/paypal-access PayPal] code [https://www.x.com/developers/x.commerce/documentation-tools/api/profile-service-api-reference userinfo]
 
** [https://www.x.com/developers/x.commerce/products/paypal-access PayPal] code [https://www.x.com/developers/x.commerce/documentation-tools/api/profile-service-api-reference userinfo]

Revision as of 16:18, 7 May 2012

For CLARIN's security for web services OAuth 2.0 was identified as one of the possible solutions. We are currently creating a test service.

Status report (A004)

Documents

Software

AS=Authorization Server, RS=Resource Server

Commercial offerings

Options for the use-case

A user accesses a web portal ("client" in OAuth2 terminology) for editing data. He logs in using SAML SSO. Somewhere in the process, the portal needs to access the user's data on service B. Using the existing SAML SSO login, the portal accesses service B without having to ask the user's confirmation again.

The access to service B can be implemented using OAuth 2.0. In this case it is a three-legged OAuth 2 flow, with three different endpoints: authorization endpoint doing user authentication, token endpoint handing out the access token (AS), and the resource endpoint providing the service to the client or user (RS).

There are several ways to do this. Let's see what existing implementations provide.

  • OAuth2lib: client does SAML SSO login. By presenting the returned attributes to the AS, it obtains an access token for the RS.
    • demo; select default-sp for Feide's OpenIdp or default-sp-userpass and login with demo/demo
    • uses Simple Web Tokens (SWT)
    • :) AS trusts RS; signed access token by shared secret
    • :(( AS fully trusts client to supply user attributes; possible solutions:
      • Either client could pass signed SAML statement from IdP to AS, which then can verify that.
        • related to draft-ietf-oauth-saml2-bearer (and expired draft-campbell-oauth-saml); AS would need to check that it was signed to the portal's SAML SP endpoint according to draft :/
        • :( would require signatures of all IdPs at each AS (in addition to clients); can be done using eduGAIN
        • :( requires patching of OAuth2lib client (and maybe SimpleSAMLphp too; mod_shib would work) to send signed SAML
        • :( requires patching of OAuth2lib AS to verify SAML (possibly with help of SimpleSAMLphp)
        • the IdP can be seen as a non-standard authorization endpoint
      • Or introduce an authorization endpoint that does SAML SSO login for the client
        • could return user attributes token to client (besides to the AS)
        • :) signed token so AS can check it was supplied by the authorization endpoint (shared secret)
        • :) client does not need to know about SAML SSO
        • :) allows to use generic OAuth2 clients (can switch authentication methods by adapting authorization endpoint only)
        • :( requires development of new service endpoint
        • :( requires patching of OAuth2lib AS to accept SWT from client
  • Apache Amber full suite
    • :( found no SAML-support (yet?)
    • :( trouble building the thing when I tried
  • rack-oauth2-provider converts a SAML assertion to a signed SWT token
    • might be an option for the authorization endpoint mentioned above?
  • oauth2-php server+client
    • not ready-to-go, but looks like it could be an alternative library to build upon
    • was able to create a client interfacing with Github
  • python-oauth2 server+client library
    • not ready-to-go, also something to build upon
  • rack-oauth2 server+client
    • nice library, not ready-to-go, something to build upon

Conclusion: it looks like most implementations are libraries, not complete solutions. I have found only OAuth2lib to provide a 'generic' AS that is ready-to-go. The downside is that it completely trusts the client to supply who's logged in, without any way to check that the IdP asserted this. Two options were mentioned to fix this. Both require some coding work.

There are a number of ways to get an OAuth2 access token. One of them is using an assertion. Another is using client credentials, or by means of a refresh token. OAuth2lib seems to support only client credentials with a form of assertion (who's logged in). When in the future other ways to obtain an access token would be required, it's advisible to look more into the other libraries that already implement these.

If the client can be trusted fully, OAuth2lib can be used directly.

Assertions

OAuth 2 supports assertions, including SAML. See also SAML-to-OAuth2 on Azure ACS, Salesforce's assertion flow, Google's assertion flow.

OAuth 2 Profile

While the OAuth 2 standards (to be) provide a basis to work on, there are a couple of decisions that need to be made when creating an implementation.

  • OAuth flow(s); this would probably be the assertion or authz code
  • Signature algorithm(s)
    • either using a shared secret: each source-endpoint combination needs to have their own key
    • or asymmetric cryptography: more scalable but used less (in OAuth 2)
  • Token format and token contents
    • two types of tokens (which can be equal)
      • as obtained from the authentication endpoint
      • as obtained from the token endpoint
    • either the token itself contains details about the user, or it is obtained separately by an API call
  • whether and when to use refresh tokens and/or expire tokens
  • ...

Token format

An access token is generated by the authorization server, and passed to the resource by the client. The resource checks if the access token is valid, before it returns its response. This checking can be either done via a call to the authorization server, or locally. In the first case the token is opaque to anyone but the authorization server, in the latter case the token needs to be structured and contain a signature that the resource can check. This signature can be either symmetric or asymmetric.

Future

How would the landscape look like in the future, and what does that mean for the authentication/authorization landscape?

  • Many services
  • Services requiring the use of other services: delegation
  • Possibly: multiple ASes
    • combined with delegation: services needing to contact different ASes
  • Possibly: service discovery

This is still mostly unexplored territory within OAuth 2.

Before we can move forward with multiple OAuth implementations that have some hope of having an AS work with a remote RS etcetera and multiple clients, the client using the same protocol to talk to multiple authorization servers, wild and crazy ideas, but what we want to get to. Having some notion of how we're all going to do discovery, is a first step that we need to take on that road for interoperability: a client across multiple authorization servers. --- John Bradley in Web Authorization Protocol WG meeting, March 29, 2012 ~1:08

Retrieved from "https://wiki.nikhef.nl/grid/index.php?title=CLARIN/OAuth2&oldid=7901"