CLARIN/OAuth2

Documents

• draft-ietf-oauth-v2 draft-ietf-oauth-v2-bearer draft-ietf-oauth-assertions draft-ietf-oauth-saml2-bearer
  • related draft-zeltsan-oauth-use-cases draft-campbell-oauth-saml draft-jones-oauth-jwt-bearer
• Introducing OAuth 2.0
• OAuth flows
• The Current State of OAuth 2
• What is 2 legged OAuth? (and what not)

Software

AS=Authentication Server, RS=Resource Server

• PHP: oauth2-php (client draft 10, server draft 20; more at github and forks; setup and testing)
• PHP: OAuth2lib RS+AS+client only for SAML authorization code
• Ruby: rack-oauth2 RS+AS+client with bearer token support
• Ruby: rack-oauth2-provider AS for SAML extension token prototype
• Java: resthub-oauth2 client
• Java: Apache Amber RS+AS+client
• Python: python-auth2 client
• Perl: Net::OAuth2 client
• R: oauth

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. Access to service B can be implemented using OAuth 2.0. 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.
  • :) AS trusts RS; signed access token by shared secret
  • :(( AS fully trusts client to supply user attributes
    • 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 (and maybe SimpleSAMLphp too)
    • Or introduce an authorization endpoint that does SAML SSO login for the client
      • :) returns user attributes token to client
      • :) 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 (no SAML support required)
      • :( requires development of new service endpoint