[Resteasy-developers] OAuth for generic services

[Sergey B. <sbe...@gm...>]

Hi

I'm going to start working on a demo showing some OAuth-like protocol for
consumers such as Messaging services being able to push the messages to
subscribers [1].

Here is some initial brain dump with various points in no particular order.
Just would like things to start moving.

Terminology: 'End user' is the entity which registers a push URI with the
server; can be a human or some web service. 'The server' - this one gets the
messages pushed to it. 'The Consumer' : this is the MessagingServer

We have different situations to deal with.
Case 1 : highly trusted and enclosed environment. HTTPS is used. The end
user simply registers the URI and its own credentials (ex: id & secret)
which can be used by the Messaging server to authenticate with the server
using say BasicAuth over HTTPS and push messages to it.

Case 2. The Messaging server knows in advance about the servers it may post
to. It's just statically preconfigured with the credentials it needs to use
when accessing individual servers. Quite realistic for simple deployments.

Case 3. A bit more decentralized.
if HTTPS is assumed, MessagingServer (MS) needs to accept self-signed certs.
What needs to be done :
3.1 The MS needs to be provided with the client identity/credentials that it
will use when pushing the messages to the server
3.1.1 End user 'owns' the server, essentially it is a web service which acts
an enduser, when receiving some inbound call. The end user dynamically
allocates the consumer id & secret and posts it to MS.
3.1.2 End user is a human, ex, the admin manually enters the push URI to MS;
or it is not collocated with the server.  In this case the end user first
goes to a 'consumer id allocation' server endpoint, gets the credentials and
posts to MS
3.1.3 MS initiates the OAuth discovery (contacting the server consumer id
allocation endpoint) when the end user registers the push URI
3.1.4 MS knows its OpenID or some token recognized enterprise-wise. We
introduce a consumer_id_type=open_id/etc. MS uses it to post to the server.
Server validates the ID with some IDM registry

At this stage we have something similar to 2-leg OAuth - no end user
authorization is needed during subsequent pushes.

3.2 MS (Consumer) optionally replaces its ID obtained at 3.1 for a
time-limited access token which can be revoked by the end user. To
facilitate it, the end user may additionally provide an authorization code
(aka verifier) or SAML token

If no HTTPS is involved then end user will need to get a shared secret
during the URI registration or upload a public key which can be used to
encrypt the messages if needed

Sergey

[1] https://jira.jboss.org/browse/RESTEASY-414