01How sign-in works
Seerio uses OpenID Connect (OIDC) with the authorization code flow. Your users never enter their password in Seerio.
- User
Opens the Seerio sign-in page and clicks the SSO button for your company.
- Browser
Is sent to your identity provider's sign-in page.
- User
Signs in with their company credentials. If they already have an active session with your provider, this step is skipped.
- Your identity provider
Sends the browser back to the Seerio redirect URI with a one-time code.
- Seerio server
Exchanges the code for tokens directly with your provider (server to server) and reads the user's email address.
- Seerio
Finds the Seerio account with that email and checks it is active. If so, the user is signed in. If not, they see an error message.
A Seerio session started through SSO lasts as long as a session started with a password.
02Requirements
Please check these points before we agree the schedule.
| Requirement | Details |
|---|---|
| OpenID Connect support | Your identity provider supports OIDC. Most do: Microsoft Entra ID, Okta, Ping Identity, Keycloak, Google Workspace and others.SAML 2.0 only is not supported at the moment. Tell us early if that is your case. |
| Email claim | Your provider returns the user's email attribute, available from the UserInfo endpoint. |
| Token signing | ID tokens are signed with RS256. Let us know if you use a different algorithm. |
| Unique, stable emails | Each user has a personal email address that does not change. Shared mailboxes used by several people (for example a front desk address) need a separate conversation. |
| User type | SSO is available for hotel users of the Seerio platform. |
| Two environments | We test on Seerio's staging environment first, then switch on production. If you use one identity provider for both, please register two separate applications (two sets of client ID and secret). |
Application settings in your identity provider
Please register Seerio as an OIDC application with the settings below. Create one registration for test and one for production.
| Setting | Value |
|---|---|
| Protocol | OpenID Connect 1.0 |
| Application type | Web application, confidential client |
| Flow | Authorization Code (response_type=code) |
| Client authentication | client_secret_postClient ID and client secret are sent in the request body |
| Scopes | openid, email, profile |
| ID token | Returned by the token endpoint, signed with RS256, public keys published at the JWKS URI |
Audience (aud) in the ID token | The client ID of the Seerio application |
| UserInfo endpoint | Returns the email attribute for the access token issued to Seerio |
| Redirect URI | The addresses from section 4, exactly as shown |
| Logout URL / post-logout redirect | Not required |
03What we need from you
We collect these separately for the test and production setups. Your Seerio contact will confirm when each item is received.
| Item | Test | Production |
|---|---|---|
Discovery URLThe …/.well-known/openid-configuration address, or the full set: issuer, authorization, token, UserInfo and JWKS endpoints | ||
IssuerThe exact value of the iss claim in the ID token | ||
| Client ID | ||
| Client secretShared through a secure channel only, see section 5 | ||
| Client secret expiry date | ||
| Confirmation that the Seerio redirect URI is registeredExactly as given in section 4 | ||
Confirmation that the email attribute is returned | ||
Name attributes (optional)given_name and family_name, if available | Optional | Optional |
| Test accounts in your systemLogin and email for each; ideally 2 to 3 accounts | – | |
| List of users to set up in SeerioEmail, first name, last name, hotel | – | |
| Technical contactName, email, phone |
04Redirect URIs
Register these addresses in your identity provider exactly as shown. Each one ends with a short identifier for your organisation (the slug), which your Seerio contact confirms at kick-off. Enter it below to get the final addresses.
Redirect URI
Login initiation URL
The address that starts sign-in to Seerio through your provider. Enter it if your identity provider asks for an initiate login URI.
Seerio environments: test runs on app.seerio.net, production on app.seerio.com.
05Sharing the client secret
The client secret works like a password. Please treat it that way.
Accepted channels
- A password manager share, for example a one-time link
- An encrypted file, with the password sent through a different channel such as SMS or phone
Please do not send it by
- Plain email or email attachment
- Chat messages
- Shared documents or tickets
At Seerio the secret goes straight to our technical team and is stored only in our server configuration.
06User accounts
Seerio recognises a user by the email address your identity provider sends. That email must match the Seerio account character for character.
One character makes a differencejohn.smith@ and j.smith@ are two different users. Please send the exact email addresses used in your identity provider.
How accounts are created
- Seerio sets up the accounts from your user list. SSO does not create accounts on first sign-in.
- A user without a Seerio account sees an error (user_not_found) and should contact you or Seerio.
- We start with your pilot users in production and add everyone else after a successful pilot. Each user then receives a welcome email.
Keeping accounts in sync
| When this happens | Please do this |
|---|---|
| A user's email changes in your system | Tell Seerio, so we update the account. Otherwise the user can no longer sign in through SSO. |
| A user leaves your company | Disable them in your identity provider and tell Seerio, so we deactivate the Seerio account too. |
| A new user joins | Send us their email, name and hotel so we can set up the account. |
Password sign-in stays availableAccounts set up for SSO can still sign in with a Seerio password, for example after using "Forgot password". This is why we also deactivate leavers in Seerio. If your policy requires your identity provider to be the only way in, please tell us before we agree the scope.
07Rollout plan
Seven stages from kick-off to go-live. We agree the dates together at kick-off.
Kick-off and requirements Together
We confirm scope and schedule, your slug and our contact person.
Test setup data You
You register the test application and send the items from section 3.
Technical configuration Seerio
We configure your provider on staging and add your SSO button.
Test accounts Seerio
We create Seerio accounts for your test users on staging.
Acceptance testing Together
We run the scenarios in section 8. You confirm by email when ready for production.
Production setup Together
You send production data and the user list. We configure production and create pilot accounts.
Pilot and go-live Together
One or two pilot users sign in on production. After your confirmation we set up all remaining users.
08Acceptance tests
We run these on staging with your test accounts and record the result of each one.
| # | Scenario | How | Expected result |
|---|---|---|---|
| 1 | Successful sign-in | Test user has a Seerio account. Click the SSO button and sign in with your provider. | The user sees their Seerio dashboard. |
| 2 | Already signed in with your provider | Repeat scenario 1 in the same browser. | No sign-in form, straight to Seerio. |
| 3 | No Seerio account | Use a test user without a Seerio account. | Error message, user_not_found |
| 4 | Inactive Seerio account | Seerio account is blocked or inactive. | Error message, auth_failed |
| 5 | Sign-in cancelled | Click Cancel or decline on your provider's page. | No access to Seerio. Depending on your provider, an error message or the user stays on your page. |
| 6 | Sign-in takes too long | Wait more than 5 minutes on your sign-in page, then sign in. | Error message, auth_failed. A new attempt works. |
| 7 | Sign-out | Sign out of Seerio, then click the SSO button again. | Signed out of Seerio only. Signing in again needs no form, as the session with your provider is still active. |
| 8 | Mobile device | Scenario 1 on a phone. | Same as scenario 1. |
| 9 | Email must match exactly | Seerio account email differs by one character. | user_not_found, which confirms exact matching. |
About sign-out (scenario 7)Signing out of Seerio does not sign the user out of your identity provider. Please confirm this behaviour works for you.
09After go-live
A few things keep SSO running smoothly.
Client secret renewal
Your client secret has an expiry date. Please send a new one about a month before it expires, through a secure channel. If it expires, nobody from your company can sign in through SSO.
Changes on your side
Please tell us in advance before you change signing keys, endpoint addresses or the application registration. Address changes need an update on our side.
Error codes
If sign-in fails, the address of the error page contains a code.
| Code | Meaning | Usual fix |
|---|---|---|
| user_not_found | No Seerio account with this email | Check the email matches exactly, or ask Seerio to create the account. |
| auth_failed | Sign-in could not be completed, or the Seerio account is inactive | Try again. If it repeats, report it to Seerio. |
| unknown | Unexpected error | Report it to Seerio. |
Reporting a problem
Every SSO sign-in attempt is logged on our side and kept for 30 days. To help us find it quickly, please send:
- The user's email address
- Date and time of the attempt, to within a few minutes
- The full address of the page showing the error
- How many attempts were made, and whether other users are affected