Download the PHP package lingoda/b2b-crosslogin-bundle without Composer

Lingoda B2B Cross-Login Bundle

This bundle provides a way to cross-login between apps on B2B.

Installation

Then add the bundle to your config/bundles.php, if it is not added automatically:

Configuration

Add the following configuration to your config/packages/lingoda_cross_login.yaml:

!!! For security reasons, the audience of a generated token on one app has to match the issuer of the other app, and vice versa. Tokens that do not match this requirement will be rejected. The audience is automatically generated from the host and port of the URL provided.

The following statements should be true, in order to have a successful cross-login:

• App A issuer ENV var = App B JWT token audience (aud)
• App B issuer ENV var = App A JWT token audience (aud)

Configuration for LexikJWTAuthenticationBundle

Add the following configuration to your config/packages/lexik_jwt_authentication.yaml:

Configuring the firewall

Then, add the following configuration to your config/packages/security.yaml:

Configuring the routes

Finally, add the following to your config/routes.yaml:

Important note!

• Keep in mind, all apps need to have the same JWT_PUBLIC_KEY value (public.pem content, not path), so the JWT token can be validated across apps.

Usage in Twig

You can use the following Twig functions to generate JWT tokens and URLs:

Use cases

1. Bypassing JWT token authentication failure

If you don't want the authentication to fail if the JWT token is invalid, expired, or not provided, you can add the BypassFailureJWTAuthenticator to your firewall's custom_authenticators:

And register the authenticator in your config/services.yaml:

2. Stateful cross-login

If you want to make the cross-login stateful, add the jwt configuration to a stateful firewall, e.g.:

Receiving a cross-login

First decide whether you need this at all

If your receiving firewall is stateful, you do not. A JWT on a stateful firewall already authenticates the request and Symfony persists a session, so every URL is a valid landing page. That is use case #2 above. Change nothing.

You need a receive endpoint only when the receiving firewall is stateless: true. A stateless app has to exchange the short-lived cross-login token for its own durable credentials — typically cookies — and that exchange is app-specific. The bundle owns the route, the claim decoding and the failure shape, and dispatches events for the rest.

The receive side is off until you opt in, so upgrading cannot give an app an endpoint it did not ask for. Opting in takes two steps, per receiver.

1. Configure the receiver

Receivers are named because one app can receive on behalf of several hosts. Override jwt_manager when the app verifies cross-login tokens with a different key than it signs its own tokens with.

2. Import the route

The bundle does not register the route itself, because only your app knows the host constraint and the ordering — in an app with a catch-all route, this must be registered before that catch-all. The route is named receive, so name_prefix is required to keep several receivers distinct. Lingoda\CrossLoginBundle\Routing\CrossLoginRoutes::RECEIVE_PATH holds the recommended full path, for senders in other apps that cannot generate the route.

3. Give the route a firewall

PUBLIC_ACCESS is required: BypassFailureJWTAuthenticator lets an unusable token through instead of returning 401, so the controller can dispatch a failure your app can redirect on.

4. Listen

Three events fire, each under a name scoped to the receiver, so a listener in a multi-receiver app can never be triggered by a different receiver's hand-off.

If no listener sets a Response the controller redirects to default_route, and on failure it adds the reason as a query parameter — ?crosslogin_error=invalid_token. The codes are missing_token, invalid_token and unknown_user (CrossLoginError). An exception message is never put in the URL.

Dependencies

• LexikJWTAuthenticationBundle is used for JWT token generating.