Headless vs Gateway

Making a decision between headless and gateway authentication integrations can be difficult. This article provides a detailed analysis of each option to guide your decision.

Cryptr is an Authorization service that centralizes your authentication, this is the “most professional” approach, the one used by the big guys. When you try to access Google Calendar, Google Drive, Google Gmail, you will be forced to be authorized by https://accounts.google.com. Once authenticated, you will be redirected to the service you requested.

You need to choose your user experience for your authentication and integration strategy with Cryptr. Do I want a code-less approach, produce little code, and centralize my user journey on the Login Gateway, and easily change my mind about which authentication strategy to adopt for which

The fallback content to display on prerendering

, without redeploying my

The fallback content to display on prerendering

?

Or do I want to embed my authentication 100% in my code, and minimize the interactions of my

The fallback content to display on prerendering

with Cryptr, but have to redeploy my

The fallback content to display on prerendering

in case of evolution?

Gateway, the self-hosted Cryptr login UI

With the self-hosted approach, when your

The fallback content to display on prerendering

log in, they are redirected to the Cryptr service, then once the

The fallback content to display on prerendering

(by password,

The fallback content to display on prerendering

or

The fallback content to display on prerendering

) is completed, they are redirected to the original

The fallback content to display on prerendering

.

All the logic of the user

The fallback content to display on prerendering

is managed by Cryptr, the transactional parts like the first connection with a password creation, find the

The fallback content to display on prerendering

of the

The fallback content to display on prerendering

who try to log in… etc. In addition, there is a system of UI templating that make you able to customize 100% of the User Interface.

👌 Fit very well with your use case if

• You doesn’t want to think about security
• You want to spend less code on the long game
• Your UX fit with 95% of common use cases
• You need to update the authentication strategy later (like replacing password by
  The fallback content to display on prerendering
  ).

👇 Prefere the headless way if

• Doesn’t fit with “very specific” UX, as you can’t custom the user
  The fallback content to display on prerendering
• You’re dealing with a lot of a legacy and need only the
  The fallback content to display on prerendering

Headless, the pure Auth API to embed in your code

The “Headless” alternative does not redirect the

The fallback content to display on prerendering

, it is embedded in the

The fallback content to display on prerendering

. Via

The fallback content to display on prerendering

calls from your

The fallback content to display on prerendering

to Cryptr, the data necessary for authentication are transmitted by

The fallback content to display on prerendering

and validated by Cryptr. You receive the final

The fallback content to display on prerendering

and it is up to you to manage the quality of the authentication integration and the session management. The approach brings flexibility to manage an

The fallback content to display on prerendering

that would have for example a constraining technical debt. But you miss out on a number of benefits that are only possible via the gateway approach by Cryptr, in terms of security and evolution.

👌 Fit very well with your use case if

• Adapted for legacy
  The fallback content to display on prerendering
• Perhaps less code on the short game
• Your customize the UX more than the Self-Hosted way (however the self-hosted is customizable enough for 95% of the use cases…)

👆 Prefere the Gateway if

• You need to update and redeploy your
  The fallback content to display on prerendering
  if you change your mind about the auth strategy
• Hard to maintain with many
  The fallback content to display on prerendering
  , as you integrate only the challenge of the authentication but directly in your code (however the integration is very light)