How to setup OAuth2 authentication
Last updated
Last updated
OAuth2 involves 5 different times to correctly setup and use it:
The OAuth2 Server administrator must create OAuth2 credentials for the specific Platform application and provides the following information:
client id
client secret
any "scopes" needed later to access specific protected resources
the access token end point (an URL)
the authorization base URL
the Platform dev must provide a callback (i.e. a public web service) that the OAuth2 Server must invoke at the end of the step 3 and pass forward the permanent code, valid per user; the OAuth2 Server administrator could have to include such callback in its configuration; for instance, in case of Google OAuth, you must include this URL in web page "Client ID for web application", related to the specific OAuth2 credentials created: Google requires that all callback URLS must be defined and authorized. The Platform dev must creates a server-side javascript action used as the callback and it must be public, i.e. includes Platform credentials, for example using api/cmd=..&applicationId=...
the user have to generate the permanent code una tantum; in order to do it, the Platform dev must create a server-side javascript action in order to generate the "Authorization request" (in the schema above); once done that, the user can authorize through its personal credentials and the callback will be invoked; the callback contains the permanent code; there should be also an application logic to store such permanent code somewhere (e.g. in a database table, a code per user)
after the generation of the permanent code, a series of calls to protected web resources can be executed; before doing it, a temporary access token must be created, starting from the permanent code (the "Access token request" described in the schema above); for example, every time the user logon into the app, its permanent code can be used to generate the access token, which has always an expiration (e.g. an hour); it is up to the application to ensure that the access token is always valid, by re-genereting it when needed
once getting the access token, this must be included in any subsequent request, when accessing protected web resources (the "Resource request" reported in the schema above)
To sum up, these can be the server-side js actions to create:
Server-side js action used by the end user to generate the permanent code, starting from
client id
client secret
access token end point
authorization base url
When this action is invoked, and authURL is dinamically generated and should be showed in the web browser window: the user must confirm its content and behind the scenes the web service provided by Platform will be invoked (callback), i.e.
For example, Google would provide this reqParams content:
The following server-side js action is used to generate a temporary access token, starting from the permanent code:
Finally, you can use it in any subsequent resource calls: