1. Home
  2. How To Dev - Authentication to API access, REST Call

How To Dev - Authentication to API access, REST Call

×

Warning message

You can't delete this newsletter because it has not been sent to all its subscribers.

 

The approaches for integrating with the platform are reported in the figure here below.


Figure: Authentication with Snap4City platform.

The Approach adopted is based on OpenAuthentication, Open ID Connect, using KeyCloak tool. For the Authorization we use LDAP for the users’ roles and the Authorization Manager. OAuth2.0 one of the most used authentication protocols for web applications, standardized by IETF, used by many big social networks (Facebook, google, twitter, github, ...)

Different cases for OAuth 2.0:

  • web server application
    • browser client and some application running on server side (service)
  • Single page App
    • application running on the browser, no specific server-side code.
  • Implicit Flow Protocol, mobile application
    • application running on mobile, no specific server-side code.
    • more secure than a stand-alone web page since some secret may be stored into the mobile app.

Please note that both client_id and client_secret have to be requested to Snap4City platform administrator. Il client_secret should be only used by server-side server which can keep it in some safe.
All the Access Token are in JWT, see them on Https://www.jwt.io

Web Server Application:

  • web browser opens the url, the HTML pages are produced by the Service, which is a Web Application, the logic is on Server Side, the service redirect on the Identify Provider.
  • The Service generates a random state string (saved in the session) and redirects to Identify provider (1)
  • (2) The Identify Provider checks client_id and redirect_uri
  • user can login (if not already done), user is requested permission for the Service and if authentication succeeds and user give permission the Identify Provider redirects (3) to redirect_uri?code=...&state=... of the Service
    • code is used to get an access token.
    • state is used to check that the call was performed by this site, an ID generated by the Service.
    • the Service receives the code and state (3) back, checks the state is the same as the one originally sent (2).
  • the Service uses the «code» to get an access token, making (4) a request to the Identify Provider in Post (this time passing client_id and client_secret, etc.). Finally, the Service receives the Access Token (5) from the Identify provider.
  • The Service can now make a request to the API to get information of the users’ data or send some data.

Single page App on some server, without web application server logic.

  • Only browser without the server-side app, or better, the service side app role is played by the Identity Provider.
  • In this case the Single Page App is running on the web browser, the client_secret cannot be used to get the access token.
  • web browser opens the url, the HTML pages are produced bringing the authentication on Identity Provider.
  • (1) The authentication of the client is performed by using the client_id, state, redirect_uri to be called and scope.
  • (2) The Identify provider redirect to the single page app since the single page is accessible as a web page.
  • (3) finally, the web page can use the received code for getting the accessToken (4).
  • Then the web page can make a request to the API to get or send information to the portal.

Implicit Flow Protocol: public applications, mobile application, (data analytics in Python and RStudio)

  • Less secure: It’s not recommended to use this flow unless you absolutely need to
    • For Front-End Web Application that do not have Server-Side functionalities.
    • It may be used from cloud data analytics processes, for example.
    • If you develop a client application in JavaScript, you can only go with this approach.
  • These clients have to use the client_id and may not use the client_secret depending on the kind of client (if application of the client_id is public the secret is not needed)
    • The client_secret has to be obtained and saved only by server applications. For example, in the case above of Web Server Application above.
  • The Mobile App use the Client_id, username and password to directly access getting the Access Token and the Refresh Token.
  • Then the Mobile App can now make a request to the API to get information of the users’ data or send some data.

 

Therefore, the Implicit Flow Protocol is the most secure and suitable for the mobile apps, the client secret can be omitted if needed.

The solutions are described in the slides of part 8 of development: https://www.snap4city.org/download/video/course/dev/

 

 

  • Share