<div dir="ltr">+1 on this scenario <div><br></div><div><br></div><div>There is a different scenario:</div><div><br></div><div>* the mobile app does not require an actual user (e.g. think about something like a News-App (e.g. "ESPN Sports Ticker")), but the device still needs to be registered w/ a server, so that the server later can use the device metadata for sending push notifications to the iOS / Android device. The AeroGear UnifiedPush Server is doing it (currently) via HTTP Basic (see [1]).</div>
<div><br></div><div><br></div><div>Is this some scenario you are interested in supporting as well? Or is the (current) focus more around storing 'devices' / 'device metadata' under a real user (which is most-likely a pure enterprise use-case)? </div>
<div><br></div><div>Greetings,</div><div>Matthias</div><div><br></div><div>[1] <a href="http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/">http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/</a></div>
<div><br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 5:30 PM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Here's my thoughts on device mgmt, both UI and protocol:<br>
<br>
Scenario:<br>
<br>
An iOS device as a "Brokerage App" installed. The app needs to do REST<br>
invocations to be able to trade stocks, etc. Devices must be registered<br>
in order to obtain permission. Flow would look like this:<br>
<br>
* User installs app on iPad.<br>
* User hits login button on app.<br>
* User is redirected to browser with a Keycloak server URL<br>
* User enters in credentials<br>
* User is redirected to "Device Registration" page. Keycloak asks user<br>
if it authorizes access to the device.<br>
* Keycloak registers the device under the user and generates a device token<br>
* User is redirected back to iPad ap<br>
* iPad app gets auth code from redirect URL<br>
* iPad makes REST request to obtain auth token *AND* a device token.<br>
* iPad app stores the device token.<br>
<br>
Next login is the same, except there is no "grant" page displayed. The<br>
iPad app uses the "device token" as a credential to turn an access code<br>
into an access token. These are all extensions we'll need to make to<br>
the current OAuth protocol.<br>
<br>
UI work:<br>
<br>
The User Account Service will need a way to list registered devices so<br>
the user can see it and manage it (i.e. remove a registered device).<br>
<br>
Admin Console should have a way to define a "Device Type". The name,<br>
description and scope of the device type is defined. "name" is used in<br>
the initial OAuth grant as a client_id identifier so that Keycloak knows<br>
what to display as a description in the<br>
<span class=""><font color="#888888"><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div></div></div>