Auth0 - SPA - Single Page application - part 2

Hello all,


As part 2 of Auth0 development, I would like to show today what you need to work on your NodeJS code to make your single page application protected and use the best features of Auth0.


1. Remeber that for single page application we use a grant flow that we call Implicit Grant. In my case, I am using reponse_type=id_token token.

Fig1: Implicit flow using id_token token

2. For SPA, we have 3 basic ways to store our token:

2.1- Using Local Storages

2.2- Using Cookies

2.3-Using Session Storages

Fig2: 3 basic options to store tokens using SPA.

2.4- The fourth option provides more protection - In-memory.

Fig3: In-memory to store a token

3. Another good recommendation is clean up as much as possible using the onbeforeunload trigger.

Fig4: onbeforeunload window script for cleaning.

4. Working with SPA, you basically have only one HTML page that uses all 'div' and 'id' created from your NODEJS code. So, having said that:

Fig5: HTML piece that loads the profileview from app.js code

5. app.js function that calls an API(/userInfo) with access_token to collect a json information about user.

Fig6: app.js function calling API(/userInfo) 

Summary:

A single-page application (SPA) is a web application or website that interacts with the user by dynamically reworking the current page rather than loading entire new pages from a server.  We avoid interruption of the user experience between progressive pages, making the application act more like a desktop application.

Advantages

1. Best responsiveness – Server-side rendering is hard to implement for all the intermediate states – small view states do not map well to URLs. Single page apps are characterized by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. 

2. Easy to deploy – A single page application is super-simple to deploy if compared to more traditional server-side rendered applications: it’s just one index.htmlfile, with a CSS bundle and a Javascript bundle. 

3. versioning and rollback – Another advantage of deploying our frontend as a single page application is a versioning and rollback. All we have to do is to version our build output (that produces the CSS and JS bundles highlighted in yellow above). 

4. Faster to load – If you have ever used a web application that is regularly reloading everything from the server on almost every user interaction, you will know that that type of application gives a poor user experience due to: the constant full page reloads; also due to the network back and forth trips to the server to fetch all that HTML. 

Disadvantages

Memory leaks – Pages are “long-lived” boosting the risk of memory leak issues. This can deteriorate UX and because of battery drain on mobile devices.

Thank you and happy coding,

Thiago Leoncio.

Download this code here.

Auth0 - how to integrate your application with this smart solution - Part 1

Hello everybody,


I would like to show today more about this great identity solution that I've been working on these days.

Auth0 widget gives you a fully customizable, enterprise-ready login/registration box with just a few lines of JavaScript, Java, Swift, or many other languages. The idea behind Auth0 identity as a service solution is to remove from your developers and time wasted with concerns about the authentication and authorization process. That alleviates and help the engineering team to focus on what is more important to the business.

Auth0 has many options for authentication, but by default, it uses OpenID connect to generate what we call IDToken and then, for authorization it uses OAuth protocol that generates and exchanges the AccessToken.

As I presented in my previous article here it's how OAuth flow works:

Here we have the most common grants and flows base on the application need:


What are the different type of apps:

1-Mobile/Native App

 - GRANT: Authorization Code using PKCE - Proof Key for Code Exchange.
 - Flow:
 1.1- Native APP(client) call /authorize endpoint
 1.2-Auth0 redirects with authorization_code in the querystring.
 1.3- Native app sends the authorization_code,code_verifier, redirect_Uri,and clientIDto Auth0.
 Using the /oauth/token endpoint
 1.4-Auth0 validates this information and returns access_token(opt: refresh_token)
 1.5-The native app can use the access_token to call the API on behalf of the user.


2-Single Page App
- GRANT: Implicit
- Flow:
1- The app initiates the flow and redirects the browser to Auth0(using /authorize endpoint),
so the user can authenticate.
2-Auth0 authenticates the user. The first time the user goes through this flow a consent page
will be shown where the permissions, that will be given to the application, are listed. For example:
post_messages, list contacts, and others.

3-Auth0 redirects the user to the app with an access_token(and optionally and id_token) in the hash
fragment of the URI. The app can extract the tokens from the hash fragment.
NOTE: In Single PAge application(SPA) this would be done using javascript and in a mobile application
this is typically handled by interacting with a Web View.

4- The app can use the access_token to call API on behalf of the user.



3-Web App

- GRANT: Authorization Code
- Flow:
1- The Web app initiates the flow and redirects the browser to Auth0(specifically to the /authorize endpoint).
So the user can be authenticated.

2- Auth0 authenticates the user, via the browser. The first time the user goes through this flow a consent the page will be shown where the permissions are listed that will be given to the application.
For example post messages, list contacts and so forth.

3-Auth0 redirects the user to the web app(specifically to redirect_uri, as specified in the
/authorize request) with an authorization code in the query string(code).

4-The web app sends the authorization code to Auth0 and asks to exchange it with an access_token
(and optionally an id_token and a refresh_token). This is done using the Cliend id and Client secret.

5- Auth0 authenticates the web app, validates the authorization code and responds back with the token.

6- The web app can use the access_token to call API on behalf of the user.

Benefits:

• Almost any web app you use is going to perform authentication. This is table stakes, and there are a lot of cookie-cutter solutions for various frameworks but can be hard to get it right and secure. One less thing to maintain and worry about when you are building your product. Their starter free plan is sufficient for most startups' needs.
• Auth0 has got SDKs in various languages and a ton of documentation. It's easy to integrate it with your demand.
• It provides compliance with various standards(Ex: HIPAA) if that's a key requirement for your outcome.

Summary:

     Learn that you are offloading your whole user data to a 3rd party app in exchange for extensibility. They do offer a way to migrate this data back to your app in case you need it, thus avoiding any vendor lock-in. In my next article, I am going provide code examples that I did integrate this excellent identity solution with my IOS, Java and NodeJS apps. Stay tuned.



Happy coding,
Thiago Leoncio.