----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Friday, 24 January, 2014 4:30:52 PM
Subject: [keycloak-dev] Device mgmt
Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
* User installs app on iPad.
* User hits login button on app.
* User is redirected to browser with a Keycloak server URL
Matt raised some issues around using a browser for OAuth2 and that Android may prevent it
in the future. I wonder if we could somehow provide a more integrated experience than
needing to use a browser. I don't really know much about app development on neither
iOS or Android so don't know how feasible that is.
* User enters in credentials
* User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
Would it make sense to have this as an optional step? We could for example allow a device
to automatically register when user logs in with his credentials, but the user would still
be able to manage the device through account management later.
We could probably also the same mechanism for html5 applications. This would work the same
way and the "device" (browser) would get a device token which is stored in
localStorage (or cookie for older browsers if we're bothered about supporting them).
This can also be used to provide
https://issues.jboss.org/browse/KEYCLOAK-242 (Add
remember machine option for two factor authentication).
* Keycloak registers the device under the user and generates a device
token
* User is redirected back to iPad ap
* iPad app gets auth code from redirect URL
* iPad makes REST request to obtain auth token *AND* a device token.
* iPad app stores the device token.
Next login is the same, except there is no "grant" page displayed. The
iPad app uses the "device token" as a credential to turn an access code
into an access token. These are all extensions we'll need to make to
the current OAuth protocol.
UI work:
The User Account Service will need a way to list registered devices so
the user can see it and manage it (i.e. remove a registered device).
Admin Console should have a way to define a "Device Type". The name,
description and scope of the device type is defined. "name" is used in
the initial OAuth grant as a client_id identifier so that Keycloak knows
what to display as a description in the
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev