Skip to main content

Spider supports OIDC!

· 3 min read
Thibaut Raballand
Creator of Spider

Spider can now authenticate users with your favorite Identity Provider using OpenId Connect.

Logo

Context​

Prior to this evolution, Spider was accepting authentication in two ways:

  • Against Spider own database, with password stored using bcrypt
  • Against a linked LDAP

Now, it is more and more required to allow authentication with the company SSO.
So being, Spider now supports authenticating to a 3rd party Identity Provider using OpenId Connect protocol.

Features​

OIDC authentication is done in parallel as others.
The user may have an LDAP or local account, and connect with OIDC.

When the user does not exist, but has a valid OIDC account, it is created with a fake random password.

Architecture​

OIDC architecture.png

Spider implements the authorization code grant:

  1. Network View and Monitoring UI redirects to Login UI
    • With user email and identity provider (IP) if the user was previously connected with OIDC
  2. Login UI redirects to the IP to get a code, using authorization_endpoint, client_id and scope
    • Automatically with an email hint when email has provided by the UIs
    • When user click on the IP name in the login page
  3. The IP validate the user session or display a login page, then validates the credentials.
  4. The IP redirects to Login UI with a code
  5. Login UI calls Customers service with the code and provider name to get the user token
  6. Customers service takes the code and exchange it to an access_token and and id_token using the client_id and client_secret
  7. Customers service validates the id_token with the public keys provided on jwks_uri
  8. Customers service gets the email from the id_token or the userinfo_endpoint using the access_token when the former is not provided
  9. Customers sends a signed Spider token when everything goes well
  10. The token is saved in local storage by the UI then used between Spider components as usual. Login redirects back to orginal UI.

This flow allows to keep the secret in the backend, not revealing it on the client side.

UI checks on refresh​

When a user is using a token generated with an OIDC flow, on page load or refresh, it redirects to the login UI with predefined parameters to check if the IP connection is still valid.
It does it with a grace period of 1 minute after login. Not to do infinite redirects 😅

Configuration​

For OIDC auth, you need to provide in the values.yml file:

  • a name to identify and display it on the login page
  • the client_id and client_secret of Spider application as registered in the identity provider,
  • the URL endpoints of the identity provider to authenticate and exchange code to token
  • the jwks uri to check the token signature

Optionally, you may have to define:

  • the OAuth scopes to use,
    • openid profile email are used as default scopes
  • the userInfo URL to get the user details when the provider does not provide an id_token with the access_token.

Check the reference documentation for more details.

UI​

The Login page is showing each Identity Providers below the login inputs.

Login with OIDC.png

Documentation​

Links to official documentation: