Single Sign-on
Single Sign-on is used by most web apps these days and is now also available in Stadium as an authentication type for its applications. To achieve this, we used the OpenID Connect authentication protocol.
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
Extract from https://openid.net/connect/
Our main goal with SSO in Stadium was to enable central user management across several different applications. With this in mind, we had a look at several well-known and popular OIDC providers and, as a start, decided to support Okta, Auth0, and Google with Azure AD soon to follow.
An essential part of user management is the assignment of roles to a user. For Stadium, this can be done solely in the OIDC provider, within the generated application itself, or independently in both. Should role assignments be done in both, a merged set will be applied to the user when they log in.
See here for more on SSO in Stadium and how to use it.
URL Editor
Our UX tests indicated that some users struggle to pass parameters between pages.
To address this problem, we completely revisited and redesigned the way URLs are handled in Stadium. Instead of a series of dropdowns, we now opted to display a URL in a javascript templated string. The result is a much more URL-like string than before, easy to understand, read and edit.
We also added a new URL Editor to quickly and easily build this templated string. In this editor, users can select the destination and select parameters from the dropdowns or just type them in.
