Explore authorization-service approach to image API auth

[zimeon]

Explore possible introduction of an authorization service that the client can interact with via JSONP, but then be able to use regular XMLHttpRequest calls based on an Authorization token that can be sent back to the same domain that issued it (because the auth service and server are on the same domain).

[azaroth42]

Reading the OAuth2 specs... it seems like we can't use it directly for our token spec as one of the requirements is that tokens are requested via POST, and JSONP can only do GET.

https://tools.ietf.org/html/rfc6749#section-3.2 says:
The client MUST use the HTTP "POST" method when making access token
requests.

Also, the request for access tokens MUST have an authorization code, previously obtained by sending a pre-established client_id. So the request looks like (from section 4.1.3):

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

OTOH, something like this would fulfill the BL use case of only validated clients being able to use the APIs.

[azaroth42]

Also, the authorization code is granted based on pre-registered client identity ... which doesn't make sense outside of the BL case, and only then when individual installations register with them. Propose that we use the structure (e.g. access_token, expires_in) etc. however

[mikeapp]

My thought was that an implementation could use the client-server interaction in the pop-up window to establish a bearer token and subsequently vend the token via JSONP. (See 4.2 for how a Javascript client might do this, also note no POST is required in that flow. The client identity would be that of the application in the login pop-up, not Mirador.) Such an implementation could allow non-browser clients to use standard OAuth (by arrangement with the service owner, or we define a service extension?). Subsequent use of the tokens in the authorization header would handled identically.

For the Presentation API, Yale would have a use case for OAuth 'confidential' clients in case of machine access to annotations for indexing. Pre-registration would not be problematic there. We also have some access-controlled images that our CS folks used for analysis.

[azaroth42]

Ahh, yes. I already do that with Google OAuth, so should work the same for other systems. But you agree that we can't do OAuth for the access_token from the image service, right?

In order to POST to get the token, the credentials to send would need to be an authorization header obtained from from the previous step, which there's no way to get at (and hence JSONP).

[mikeapp]

I completely agree what we are specifying with JSONP is not related to an OAuth flow.

[zimeon]

I think we have explored, prototyped and agreed to go with this authorization-service approach and thus this issue can be closed (and #9 which spawned it)

[azaroth42]

+1 from eds