Popup vs. Current
Overview
When the application is running in a web context, Auth Connect provides two different options for presenting the
authentication page: popup
or current
. Up to this point, we have been using popup
. In this tutorial we will
explore current
.
popup
With popup
, the authentication provider is opened in a new browser tab / window. This mode is the most consistent
with how Auth Connect works on mobile where the authentication provider is displayed in a secure web view. On the
web, this option requires no extra code, but it may not be the best user experience for web.
If your application is only distributed as a web-native mobile app, and the web-context is only used for
development, then it is best to use popup
.
current
With current
, the authentication provider is opened in the current window, replacing your application. Your
application will then be restarted with token information on the URL upon successful login. Since this is fundamentally
different than the mobile implementation, it also means that special code is needed to handle it.
If your application is distributed in a web context, it is worth considering using current
for an improved
user experience.
General Strategy
When using popup
, it is very common to have login logic such as the following in the component used for
authentication:
_10const signinClicked = async () => {_10 try {_10 await login();_10 router.replace('/');_10 } catch (e) {_10 loginFailed.value = true;_10 }_10};
With this code:
- The
login()
is called and Auth Connect opens the OIDC authentication provider in a new tab (web) or a secure web view (mobile). - Auth Connect listens for that tab or secure web view to close.
- If the user successfully logs in:
- Auth Connect unpacks the data sent back when the tab or secure web view is closed and creates an
AuthResult
. - Our
login()
stores theAuthResult
and resolves.
- Auth Connect unpacks the data sent back when the tab or secure web view is closed and creates an
- If the user cancels the operation, our
login()
rejects with an error.
Since current
only applies to the web, this code will still work like this on mobile. However, in a web context
our app is completely replaced by the OIDC authentication provider's login page. As such, we are no longer awaiting
the login and need to use a completely different mechanism to capture the authentication result when the app restarts.
On web, the flow becomes:
- The
login()
is called and Auth Connect replaces the application with the OIDC authentication provider's login page. - The user logs in or cancels.
- The application is restarted using the configured
redirectUri
. - In the case of a successful login, the authentication information will be included in the URL. It will need to be processed by our application.
In our case, the application is using the /auth-action-complete
route. We can then use the page for that route
to perform the following tasks:
- Determine if the application is running on the web.
- If so:
- Call a process that will examine the extra parameters for the URL.
- If parameters exist, this was a successful login, and the parameters are used to construct an
AuthResult
which is stored in the session vault. - If parameters do not exist, this was a logout and the session vault is cleared.
- If parameters exist, this was a successful login, and the parameters are used to construct an
- Continue navigation to the appropriate page within the application.
- Call a process that will examine the extra parameters for the URL.
Let's Code
This tutorial builds upon the application created when doing the getting started tutorial and
converts it from using popup
to using current
. If you have the code from when you performed that tutorial,
then you are good to go. If you need the code you can make a copy from
our GitHub repository.
The Authentication Composable
The first thing that needs to be done is to modify the Auth Connect configuration to use current
mode on the web.
A function is then created that handles the URL parameters when Auth Connect restarts our application after login
or logout.
Start by having a look at the current configuration that is used for our AuthConnect.setup()
call. Note that it
is using a uiMode
of popup
.
Also note the return URLs. The page(s) accessed by that route is where we need to eventually modify.
Change the uiMode
to current
.
Since we will be coming back into the app after login, we need a function to handle that. For now just read the URL search parameters.
If search parameters are present, then this is the login returning. We package the data and send it to Auth Connect
to process and create an AuthResult
.
If there are no parameters, we will assume a logout and set the authResult
to null
.
Either way, we will save the current authResult
.
Start by having a look at the current configuration that is used for our AuthConnect.setup()
call. Note that it
is using a uiMode
of popup
.
Also note the return URLs. The page(s) accessed by that route is where we need to eventually modify.
Change the uiMode
to current
.
Since we will be coming back into the app after login, we need a function to handle that. For now just read the URL search parameters.
If search parameters are present, then this is the login returning. We package the data and send it to Auth Connect
to process and create an AuthResult
.
If there are no parameters, we will assume a logout and set the authResult
to null
.
Either way, we will save the current authResult
.
URLSearchParams.size
is supported by all modern browsers.
If you need to support older browsers, you can use Array.from(params.keys()).length
in place of params.size
.
Auth Action Completed Page
The Auth Connect configuration for the application redirects back into the application via the
/auth-action-complete
route. The code needs to determine if we are running in a web context, and if so:
- Handle the authentication.
- Route back to the root page.
The AuthActionCompletePage currently just contains markup to show a spinner. No logic is in place.
Import Capacitor so the page can determine if it is running in a native context or not.
If the application is not running in a native context, handle the return from the OIDC authentication provider.
Once the URL has been handled, redirect to the root page.
The AuthActionCompletePage currently just contains markup to show a spinner. No logic is in place.
Import Capacitor so the page can determine if it is running in a native context or not.
If the application is not running in a native context, handle the return from the OIDC authentication provider.
Once the URL has been handled, redirect to the root page.
Note: for this application, redirecting to the root page is the correct thing to do. In a more complex application, it may be more appropriate to check various states before determining the route. If so, such logic should be abstracted into a routing routine.
Next Steps
If you have not already done so, please see the following tutorials:
Happy coding!! 🤓