Implicit flow diagram

Implicit flow in case of spa (with/without backend)

• The request to authorization end point should be either done in   
  • popup via window.open , if the user is not allready authenticated. The navigation to authorization end point should be full page navigation so that the cookies which will be sent in response by authorization server will be first party cookies .(which can later on be sent in cross origin requests).Note that data: URLs get a new, empty, security context. End user interacts with authorization server before authorization response is sent. The Authorization Response is passed to the Main Window from the new window using Web Message through the JavaScript.
    • If the authorization request is ajax then since cookies are not set by a toplevel navigation (cookies are a response to cross origin ajax request,(as origin domain of spa -from where the spa is downloaded  and authorization end point domain are not same), hence the cookies will be third party cookies which many browsers no longer support or plan to stop support in the future.
    • ajax will also not support response_mode=form_post , where the response is not a redirect , it is a form which must be loaded and posted back. note that response_mode form_post is the recommended mode for authentication only use case. (the id_token will not be exposed in the front channel) Read more here
  • hidden iframe created by main window.  It is expected to be used when the End User is in the "authenticated"  state at the Authorization Server so that prompt=none succeeds.(silent authentication, no user interaction) Authorization Server SHOULD not send Set-Cookie header in the response.(as the cookie will be third party cookie as iframe navigation reqeust will still lead to 3rd party cookie as the origin of spa page which loaded the iframe and src of iframe="authorization server end point" are not same  ie the frame is a cross domain iframe, the cookies which will be loaded in response to cross domain iframe navigation will be third party cookies. ie for cookies to work in cross domain iframe, third party cookies should be enabled. Authorization Server determines if the End User is logged in state and checks if it can return the Authorization Response without interacting with the User. The Authorization Response is passed to the Main Window from the iframe using Web Message through the JavaScript.  For the cookie to go to samesite attribute of cookie must be set to none and also cookie must be secure.  Read more here.
  • note that response_mode is web_message.
  • Note that The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.
• The authorize end point will redirect with access token in custom redirect URI. 
  • note that it is mandated that the redirect URI of an OAuth 2.0 public client must be registered with the OAuth 2.0 authorization server beforehand and verified against the redirect URI in the authorization request, which will be used to deliver the access token and ID token. 
  • note that typically resposne_mode=fragment in case of spa without backend which prevents the access token from being sent to back end and being logged in some http log file.If response mode is fragment (when back end does not exist) then risk can be reduced by using session history mangement api to remove id_token from address history. Also when response mode is fragment , authorization response parameters are encoded in the in the URI Fragment Identifiers added to the redirect_uri when redirecting back to the OAuth Client. The Client needs  handle the redirect and  parse the fragment encoded values and pass them to on to the Client's processing logic for consumption. 
• The spa should store the access token in memory (javascript variable). Note that self cotained access tokens have short life as they cannot be blacklisted by auth server.
• The access token is visible as part of the URL address bar to end users at the user agent. This increases the risk of attackers stealing the access token.
• The redirect_uri gets stored in the browser’s history which exposes the access token. Some users sync their browser history which further increases security risk. This risk can be mitigated by the fact that session history mangement api can be used to remove tokens from address history. XSS attack can steal tokens by parsing url fragment.
• The redirect URL including tokens may get logged on the redirect step, in an intermediate proxy server’s  logs.

• Note that refresh tokens are not issued in implicit flow. (it is too unsafe for that for above reasons and refresh tokens have longer life  as compare to access token further increasing risk)

• implicit flow in case of spa is exclusively used in the hybrid flow, where your application requests a code as well as a token from the authorization endpoint. This leads to reduced page rendering time in both spa and webapps as the page load is not blocked for authorization code's redemption for tokens.
• For spa with back end , implict flow with response_mode=form_post can be used in authentication only use case as id_token is not found in browser history . Since access token are not required, access token refresh problem is not there . Implict flow with response_mode=form_post should not  be used in authentication and authorization use case as refresh tokens are not issued and silent authentication can have usability issues.(when the webserver detects on api request that access token has expired , it cannot use refresh token and flow has to go back to browser for silent authentication from iframe , increasing complexity and latency).

Implicit flow in native app (not recommended)

While implicit flow could be intiated with external user agent (browser) it is not recommended as risk of  token interception attack is there , as there is no reliable way to ensure that the binding between a given redirect URI and a specific mobile application is honored. Any app on the device can try to insert itself into the redirection process and cause it to serve the redirect URI. Hence the attacker can steal the access token. ie the token can be intercepted by malicious application. For this reason for native apps, authorization code flow with pkce is recommended.

Note that however direction of authorization end point in case of native apps is a top level navigation request to authorization end point and the cookie set in response will be a first party cookie. 

Implicit flow in web app 

Implicit flow with response_mode=form_post in case of webapp does not have issue of tokens getting exposed in browser history and does not have thirdy party cookie issues (A redirect to authorization end point will be a top level navigation by user and auth cookie will be set in response to top level navigation ) yet it should be used only in authentication use case and not authentication plus authorization use case because of usability issues.

• The user hits client webserver end point with certain parameters say http://clientapp.com/ep?p1=v1,p2=v2
• The client webserver after receiving the request has to use access token to hit resource server .
• If the access token has expired, the client webapp must redirect to authorization end point (for silent authentication) with state parmater value in such a way that entire context of the user request is known.
• The authorization end point will return a form with tokens and state as hidden params and with action as client redirect url , say http://clientapp.com/callback.
• Client redirect url based on state must be able to handle user request based on state parameter .
• If hybrid flow is used then this problem would not be there as refresh token would be avalaible with client webserver and it can refresh the access token.