Since the draft is close to final, I wanted to write to the list about a use case in a project that I’m working on that I think is valuable input into the Device Flow discussion.
This use case exercises the device flow OAuth extension grant in an interesting way. The usual line of thinking for using this flow is that there’s a disadvantaged device, like a set-top box, that the user needs to grant access to using a separate personal computer. In this use case, there are still two devices but it’s the permissions that vary between them, not the platform capabilities. The device ultimately getting the access token is the user’s personal mobile device (a phone or tablet), but they’re unable to log in and authorize the device directly on the device itself. Instead, the user needs to bring their device to an authorized kiosk staffed by a trained entity who has the authority to onboard the device to the user’s account. Good news is that so far we’ve been able to build this out using the device flow with no modifications to the protocol, but since our use is different we thought it would be good for the community to see its details. The flow starts with the user on their device, we’ll use a smartphone in our example. The user provides an identifier to their account, and the device starts the device flow to the server including this identifier as an additional parameter. The AS generates a device and user code pair and ties that to the account indicated by the identifier. Later, the user brings their device in to the staffed kiosk, where the authorized staff verifies the user (using a physical ID card) and the device (using the user code) against the “pending” requests for that user’s account. The staff person makes sure that the user who’s present is the same as the user in the pending request and approves the connection. At the AS this sets a flag on the device code and binds it strongly to that user’s account. Note that it’s the staff person who’s logged in, but the binding is to the proofed user’s account. This decision is written to an audit log (a good potential application for the SecEvents group, since it’s an event with multiple parties that needs to be verifiable). Later, the user gets their device online again and it trades the device code for the access token, and now it can call the APIs as needed. The time gaps in this use case are much larger than is typical with the device flow. When setting up a set-top box, it would be expected that everything gets set up within a few minutes. However, the requirement for the user to potentially travel to a trusted kiosk means that our device codes last for up to a week. And once the device is approved by the authorized staff person at the kiosk, the user has *another* week to get their device back online to trade the device code in for an access token. If either of those windows are missed, they have to start the whole process over again. Apart from the account identifier in the initial request for the device code (which we read as being allowed), there are no changes to the device code flow protocol. The account identifier is more for increasing the usability of the entire system, as it allows a user’s pending devices to be verified more quickly at the kiosk. Also, in this particular deployment, it’s used along with dynamic registration and private_key_jwt authentication for the clients, which allows for greater security for the overall protocol and greater separation of client instances from each other. We’re interested to hear people’s feedback on our use of the device flow, and curious if anyone else is using it in a similar fashion. Even though it’s different, it still fits the spirit of “two devices with different capabilities” present in the draft. — Justin _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
