Difference between revisions of "Device flow usecase 1"
Pavel.lobko (talk | contribs) |
Pavel.lobko (talk | contribs) (→Device Flow) |
||
| Line 1: | Line 1: | ||
= Device Flow = | = Device Flow = | ||
| − | Provided by i2Rest-client OAuth 2.0 Device flow allows your IBM i application to deal with protected user data on remote resource, while end users are not forced to share their usernames, passwords, and other private information. Instead, user jast have to pass authetification on remote resource and authorizate IBM i application to make some actions on the user's behalf. As far IBM i have no ability to display a web-page, i2Rest-client only provides user with link to authorization page. After user follow the link on any orher device (or via browser) and accept request, i2rest-client will be granted for authorization token, which allows user data access. | + | Provided by i2Rest-client OAuth 2.0 Device flow allows your IBM i application to deal with protected user data on remote resource, while end users are not forced to share their usernames, passwords, and other private information. Instead, user jast have to pass authetification on remote resource and authorizate IBM i application to make some actions on the user's behalf. As far IBM i have no ability to display a web-page, i2Rest-client only provides user with link to authorization page. After user follow the link on any orher device (or via browser) and accept request, i2rest-client will be granted for authorization token, which allows user data access. Lets walk step by step on schema throuth our example with creating "i2rest.doc" file on "i2restexample" user's Google Drive. |
| + | [File:Flow.png] | ||
| + | === Preparations === | ||
| + | At the very begining your application should be registrated as a client (obtaining Device ID and Device Password) on the resource that will be re | ||
| − | + | quested for protected data. In our case we should folow Google's [https://console.developers.google.com/apis/credentials instructions]. | |
| − | |||
| − | |||
| − | |||
step 1 | step 1 | ||
Revision as of 11:11, 5 April 2020
Device Flow
Provided by i2Rest-client OAuth 2.0 Device flow allows your IBM i application to deal with protected user data on remote resource, while end users are not forced to share their usernames, passwords, and other private information. Instead, user jast have to pass authetification on remote resource and authorizate IBM i application to make some actions on the user's behalf. As far IBM i have no ability to display a web-page, i2Rest-client only provides user with link to authorization page. After user follow the link on any orher device (or via browser) and accept request, i2rest-client will be granted for authorization token, which allows user data access. Lets walk step by step on schema throuth our example with creating "i2rest.doc" file on "i2restexample" user's Google Drive. [File:Flow.png]
Preparations
At the very begining your application should be registrated as a client (obtaining Device ID and Device Password) on the resource that will be re
quested for protected data. In our case we should folow Google's instructions.
step 1 With Device ID and Device Password I2rest requests URI specified in «OAuth2 authorization endpoint» parameter. Authorization server responds with some requisites to be used getting user permission to protected data. As far as AS400 have no ability to display web page, it only displays link to authorization page to visit via browser according to «show authorization screen?» parameter.
If case of *REQUESTER or *BOTH authorization srcreen will be displayed. In case of *NONE or *REMOTE no screen will be displayed, but requester or specified (Send authorization request to) User should get notification.
That notification is handled by *DFT program, that gets Authorizer field with specified length as input parameter.
Any program with custom logic (sms notification, etc) can be applied. During period of «Time to wait authorization» i2rest will poll «OAuth2 token endpoint» URI to get token, which should be issued after user authorizes request. Tokens obtained from the authorization sever will be saved to “Tokens storage”.
