Hi,

Stian Thorgersen <stian@redhat.com> wrote on 24/06/2015 15:00:18:

> We'll be adding service accounts in the near future, that'll provide
> a way for clients to obtain a token on behalf of themselves. There
> will be a special linked user to the client. Clients can obtain this
> through the client credential grant (see oauth2 for more details)
> and use a secret or pub/priv keypair to authenticate.

that sounds great.
 
> For a client to get a token on behalf of a user the user will have
> to either enter username/pass in a cli and you'd use resource owner
> credential grant (again see oauth2 for more details) or you'd use
> the normal redirect based flow.
>
> For the above once we add offline tokens this will only be required
> as an initial setup as the "refresh token" will not expire until the
> user goes in and revokes access to the appliction.

That's actually the initial setup that I would like to avoid. If we talk about social websites this flow makes absolute sense, as I as the user want to control what data can be accessed by external services. However, in an enterprise application the user shouldn't be bothered with single microservices IMO. Therefore, when I ask the user to authorise some arbitrary backend service to access some data, the user will probably be surprised or, even worse, confused.

Currently I only see three possible solutions:
1. Do it as you propose and implement the OAuth flow.
2. Add some additional API and options to allow clients to request access tokens on behalf of users (maybe with reduced privileges only).
3. Somehow let the service figure out the access rights of the user, e.g. by using the admin API (haven't really checked whether that would work at all).

I don't like 3 because a) I don't want to provide admin privileges to my services and b) I don't like the fact that authorisation would work differently in that case. I definitely prefer 2 over 1, because I think it will provide the best user experience. My hope was that there is some other option to handle that use case that I wasn't aware of.

As a general question, would such a feature fit into keycloak, or is out of consideration because it is not standardized?

best

Carsten

---

Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff@kisters.de | WWW: http://www.kisters.de

---

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.