Skip to main content

Authentication

There are three ways we authenticate access to self service features:

  • Email and password - standard customer facing login
  • Masquerade - support user login
  • Expiring URLs - access to particular features via a link (usually sent to the customer via and email from Kraken or an customer service user)

The end result of each of these processes is a Kraken token. To learn more about the mechanisms of authentication end to end, please see our Guide to Authentication.

Login​

This is the standard login page where a user puts in their email and password. Here is what that looks like in an app:

Storybook

Masquerade​

This is how a support user in Kraken can log into the consumer site for that Kraken instance with a customers user details, to see the site as the customer sees it.

Expiring URLs​

This is how a user can access various features without having to log in at all, generally via a link sent in email. We use this for features that have a very high value to the business. These features therefore require the friction for the customer performing the given action to be as low as possible. These URLs might be sent by a support user, or automatically via Kraken. In Blueprint, these URLs are supported by providing a dynamic route which takes a preSignedKey which we exchange for an authorization token with limited scope, and set a cookie with that token using middleware. preSignedKeys are generally scoped to allow the user to perform particular actions. Some examples are to provide feedback on a customer service interaction or a meter reading. By limiting the scope to particular actions, we reduce the impact of these urls being accidentally shared by the customer, since the actions that can be performed with them are limited.

Expiring URLs step by step​

  1. To see this feature in action, we first choose which expiring url we'd like to access. You can see which are supported in a given app in the src/pages/anon directory. All apps support the customer service feedback url, so we'll use that for our example. We assume for our example that your Kraken has a customer feedback form set up and you've generated a customer feedback object for your chosen test account. You can read more about that setup on the Global Technical Guide.

  2. Next we need to generate a preSignedKey. You can generate that in your test Kraken environment using the 'Generate an expiring URL' recipie and your chosen test account. Kraken will generate a full example url, but the preSignedKey is the bit that follows key=. We then provide this to our chosen route, so for example, if your local server is running on port 3000 and the KRAKEN_ENDPOINT is set to your test Kraken, you can use:

    localhost:3000/anon/<key_goes_here>/<account_number_goes_here>/<feedback_form_id_goes_here>/<feedback_id_goes_here>`

  3. This is where the middleware is invoked. We define the following matcher configuration setting which is then triggered for all routes under pages/anon:

    matcher: ['/anon/:path*'],

    The pre-signed key is taken from the dynamic route's parameters and exchanged for an authorization token by passing it as an input value of the obtainKrakenToken mutation. Upon a successful response from the obtainKrakenToken mutation, the Authorization token is stored in a cookie with a key named scopedToken. This cookie will then be stored within the client's browser storage when the response is provided from the middleware handler. The middlewareSetScopedTokenCookie is responsible for handling and creating this cookie and is located within packages/core/middlewares for usage by all apps. The expires option is used to ensure the cookie is removed from the browser storage after a pre-determined period. This value is set to the exp value taken from the payload object within the obtainKrakenToken mutation response.

  4. This should then render the customer feedback form for that account and allow the user to submit feedback.

Security of Expiring URLs​

There are three configured options being utilised when the cookie is created to ensure the security of the Authorization token. The 3 options in use are as follows:

Note: Secure is only set when the environment is production to avoid issues with local & test environments using http.

By employing all 3 options in conjunction, we provide a solution that ensures the token is not publicly exposed during requests and is not susceptible to XSS attacks by preventing client-side access to the stored token (in accordance with OWASP recommendations).