Hi Nat,
Starting from a standalone use case would be good.
My impression (I may be wrong) is that your requirement is to be able to
(1) Log the user identifier of the person who is accessing the resource at the
resource server for the audit etc. purposes.
<acl> yes ... that *and* to authenticate the user in the first place. So
again, my access_token will actually look like the Connect id_token. I would
even prefer to use the id_token, except that it violate the spirit of Connect
to pass the id_token to the RS (e.g. it was only meant for consumption by the
client).
My problem space can be distilled to something very simple.
- We come from a SOAP API world where we use WS-Trust to secure the
SOAP API calls. WS-Trust makes it very simple for a WS-* client to collect the
user's primary credentials, exchange it for a (SAML) bearer token via the STS,
and embed that bearer token in SOAP-based API calls to the WS-* server. This is
most definitely *authentication*
- We are moving to a RESTful API world. I just want to be able to do
the same thing as above. How do I enable my REST-based client to collect the
user's password, exchange it for a (JWT) bearer token via the STS, and embed
that bearer token in RESTful API calls to the REST-based server, such that the
REST-based server can *authenticate* the client?
(2) Do the holder of the key so that the RS is sure that the person accessing
with the access token
is really the person.
<acl> that would be nice, but most of my users will be using passwords in the
beginning, so this is not an option. I'm using the literal definition of
bearer token here, taken straight out of the OAuth bearer token spec, e.g. "Any
party in possession of a bearer token (a "bearer") can use it to get
access to the associated resources (without demonstrating possession of a
cryptographic key)."
(3) In addition, the RS may not be able to talk to AS directly.
[Well, this is one of my use case anyways.]
<acl> Right ... this is why I am now looking at structured JWTs.
(4) In some cases, the client may not be able to communicate with AS directly
at the time of RS access. [ditto]
<acl> Right again, we have disaster scenarios to think about where the AS might
not be reachable. but this is a use case for next steps. Trying to walk
before we fly here :-)
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
