CLARIN/OAuth2
Documents
- draft-ietf-oauth-v2 draft-ietf-oauth-v2-bearer draft-ietf-oauth-assertions draft-ietf-oauth-saml2-bearer
- Introducing OAuth 2.0
- OAuth flows
- The Current State of OAuth 2
- What is 2 legged OAuth? (and what not)
- tokens: Simple Web Token (SWT) JSON Web Token (JWT)
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.
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.
- uses Simple Web Tokens (SWT)
- :) 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
- :( requires patching of OAuth2lib to accept SWT from client
- Either client could pass signed SAML statement from IdP to AS, which then can verify that.
- 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
- python-oauth2 server+client library
- not ready-to-go, also something to build upon
