For 3rd party app, the app would just use OAuth protocol to obtain a
token. That's what OAuth was originally written to do. OpenID Connect
just extended it for authentication.
On 11/3/2015 1:10 PM, Pål Orby wrote:
Ok, so after reading the replies here I understand that it isn't
offline
tokens I'm looking for.
The token I'm looking for is what I would call an "application token".
Any plans implementing that?
Example:
If you enable two factor authentication on Github, you can't connect
with username/password anymore in terminal or other 3. party
applications integrated with GitHub without using an "application token"
that you create on your GitHub account page.
/Pål
*Pål Orby*
UNIT4 Agresso AS*
*Programvareingeniør
Tlf: 22 58 85 00
Mobil: 900 91 705
SendRegning - Gjør det enkelt!
http://www.sendregning.no
http://facebook.com/sendregning
http://twitter.com/sendregning
http://faktura.no
2015-11-03 13:49 GMT+01:00 Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>>:
On 03/11/15 09:32, Thomas Raehalme wrote:
> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen
> <<mailto:sthorger@redhat.com>sthorger@redhat.com
> <mailto:sthorger@redhat.com>> wrote:
>
> * Create service account for customers - they can then use
> this to obtain a token (offline or standard refresh) using
> REST endpoints on Keycloak
>
>
> Sorry to step in, but could you please explain the use case or the
> reasoning for offline tokens on service accounts? If I have
> understood it correctly you'll still need clientId and secret to
> generate the access token from the offline token. Why not just use
> them to login whenever necessary? Thanks!
We support offline tokens for service accounts because there is no
reason (bad side effect) of not supporting it. Or at least I am not
aware of any. Are you? Adding this support came "for free".
One usecase when it can be useful is, for example if you have
offline token and you don't know how was this offline token
authenticated (if it was direct grant, service account or browser).
You can send the refresh token request with this token regardless of
the offline token type as the refreshToken endpoint is same for all
cases.
Marek
>
> Best regards,
> Thomas
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user