One sign-in, two organisations.

01 / Context

The problem

Link needed to support users from two organisations, each with its own Okta tenant. The integration needed separate provider configurations, a way to choose the right one, and access controls around the application’s UI.

02 / Responsibility

My contribution

I implemented and tested single sign-on for two organisations using OIDC, Okta and django-allauth, with automatic email-domain routing. A follow-up added authenticated access to a related service.

03 / Approach

Key decisions

I followed an established internal multi-tenant integration pattern, adding a custom provider for the second tenant and routing sign-in by email domain. I then made authentication the default for UI views, with explicit exemptions for endpoints such as health checks. For the related service, I added signed tokens so authenticated support users could open the relevant message archive from Link.

1. 01

   Route

   Choose the organisation’s identity provider from the user’s email domain.

2. 02

   Authenticate

   Complete sign-in through the appropriate OIDC configuration.

3. 03

   Protect and connect

   Require login for UI views and sign access to the related service.

04 / Result

The result

Delivered and tested SSO for two organisations, automatic tenant selection and login/logout controls. The follow-up protected UI views by default and connected authenticated users to the related service’s filtered archive.