Dear all, [Updated ]Device flow support for WSO2 Identity Server.
For the earlier design, we need to store client credentials and access tokens in a database for further usage. But that thing may cause security risks. Due to that, the design was changed. New Design:- The previous design was designed to deploy the device flow component as a proxy server, completely outside of the Identity Server. But now it is designed to deploy inside the identity server as a new component of the IS. All the requests that I have used to call between the proxy server and Identity Server are now internal calls. [Step 2] and [Step 3] in the old design are removed because now the component can directly validate the client. And component will use the same IS database to store its data other than using a database for itself. The token endpoint will be the token endpoint in the Identity Server. Thank you, Best regards, Ayesha On Wed, Jul 31, 2019 at 1:05 PM Ayesha Jayasankha <[email protected]> wrote: > Hi all, > Some times users have to give their credentials to smart TVs, IoT > devices, etc. Normally they are using the Resource Owner Password > Credential (ROPC) grant type to give access to those devices. But they face > some issues with this grant type in some devices like, > > - Devices that have a problem with lack of browser > - Input constrained devices > - Security issues > > > To overcome this issue, “*OAuth 2.0 device authorization grant protocol*” > was designed. This is an OAuth 2.0 extension that enables devices with no > browser (e.i IoT devices) or limited input capability (ex: smart tv) to > obtain user authorization to access protected resources. The overall flow > is something like this. > > [image: Blank Diagram (4).png] > > (A) - Client requests access from authorization server including its > client identifier > (B) - Authorization server issues device code, end-user code, end-user > verification URI > (C) - Client instructs end-user to visit provided URI using a secondary > device (eg: mobile device). The client provides the user with the end-user > code to enter in order to review the authorization request. > (D) - Authorization server prompts the user for granting access via > user-agent, at this point the user has to enter the end-user code as well. > (E) - While end-user reviews user credentials and consents, the device > starts polling along with client id and verification code to check the > status of user authorization > (F) - The authorization server validates the verification code and > responds back with an access token to the device once the user provides > authorization > > > > I am currently doing "*support for auth device flow in WSO2 server*" > project. But adding this directly to WSO2 IS will slow-down its overall > process because of polling. Therefore it was discussed to introduce a proxy > server to connect WSO2 IS with the device flow component. This is the > sequence diagram for that flow. > > *Sequence Diagram* > > [image: Blank Diagram.png] > > Appreciate your feedback on this. Thank you. > > External ref - > *https://alexbilbie.com/2016/04/oauth-2-device-flow-grant/ > <https://alexbilbie.com/2016/04/oauth-2-device-flow-grant/> > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15 > <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15> * > > -- > *Ayesha Jayasankha* | Trainee Software Engineer | WSO2 inc. > (m) +94719147060 | (e) [email protected] > [image: http://wso2.com/signature] <http://wso2.com/signature> > -- *Ayesha Jayasankha* | Trainee Software Engineer | WSO2 inc. (m) +94719147060 | (e) [email protected] [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
