CLARIN/OAuth2 use case report

<sidebar>

• CLARIN web service security
  • CLARIN/Security_for_web_services|Analysis
  • CLARIN/OAuth2|OAuth2
  • CLARIN/OAuth2 use case|OAuth2 use-case
  • CLARIN/OAuth2_real_world_usage|OAuth2 elsewhere
• resources
  • https://mailman.nikhef.nl/mailman/listinfo/biggrid-clarin-security-discuss%7Cmailing list
  • http://agenda.nikhef.nl/conferenceDisplay.py?confId=993%7Cworkshop 2010
  • http://www.clarin.eu/%7CCLARIN
  • http://www.biggrid.nl/%7CBiG Grid

</sidebar> This page has been superseded by a report.

---

Notes for the CLARIN/OAuth2 use case report. Curently, there are two versions of the document: Status report (A004), and (A005) - the latter is not public yet.

The report will probably contain two parts: scalable OAuth2, including how to handle multiple organisations; and details about the use-case implementation. Main sources of information are the documents, previous mails on the mailing list and these wiki pages.

Scaling OAuth2

(A005) contains a number of ideas on how to use OAuth2 in a cross-organisational / federated context. One question is the authorization server: a single instance (most probably in a fail-over setup on multiple locations), or multiple instances, either constantly in communication, or using asymmetric cryptography (but then comes the issue of key management as well; discovery is another issue). This is largely an unsolved problem in the OAuth2-world. Things like discovery are being discussed on the OAuth2 mailing-list (including drafts and existing approaches).

Use-case implementation

This will probably be the most important part of the document.

This is explained on the use-case page, and a README in the github repository.

Some additional notes on the high-level overview would be useful.

Delegation

This use-case does not address delegation directly. It would be useful to mention something about that. At the end of 2012, there has been a little discussion on the OAuth2 mailing-list, and several drafts with different approaches are available. This should be somewhat documented on these pages or the mails already.

One idea is to allow the resource to request a new access-token (using its own resource-credentials). Another idea is to re-use the token (but then tracability might become a problem; though perhaps not).