Skip to content

Overview

Greg Bowler edited this page Nov 1, 2026 · 3 revisions

When someone visits our application, there are two separate sessions to consider: the application's session and any session held by the Authwave provider. The PHP client reads and writes the application's session. The provider handles its own authentication screens and session.

Following a login

We construct Authenticator early in each request, before sending any output. On an ordinary visit it restores the user from stored session data, if any exists.

When the visitor chooses to log in, login() creates a token, stores it in the application session and redirects the browser to the provider. The request contains an encrypted message and the deployment ID taken from our client key.

The requested return destination defaults to the current request URI. We can choose another application route with setReturnUri() before starting login. The provider validates the destination against the deployment's configured client origin and remembers it through the authentication steps.

After authentication, the provider sends the browser to that destination with an AUTHWAVE_RESPONSE_DATA query parameter. Constructing Authenticator on this return request decrypts the response using the stored token and the client secret. The client stores the user, invokes onAuthenticated if one was supplied, then redirects to the same URI with the response parameter removed.

On the next request we read the user from the session. There is no need to process the encrypted response ourselves.

The objects we work with

Authenticator is the main entry point. Most applications only need its login(), isLoggedIn() and getAuthUser() methods, together with an optional authentication callback.

AuthUser contains the user's ID and email address. It is a snapshot of the data received during authentication, rather than a live connection to the provider.

SessionData, Token and the provider URI classes support the exchange. We usually let Authenticator create these for us. They are available when an integration needs more control, as described in Sessions and redirects and the API reference.

The provider and the application

Register the application deployment with the provider and use its corresponding client key. Each environment needs a matching provider configuration and return location.

The provider determines how visitors authenticate and which data is returned. The application decides how to use that identity, how to associate it with local records, and which resources it grants access to.


Next, build a first working page with the Quick start guide.

Clone this wiki locally