Skip to main content

Single Sign On (SSO)

Introduction​

myDevices end-user application supports Single Sign On with your preferred Identity Provider. In this scenerio, user federation such as user login and registration is automatically handled by an external Identity Provider. At this time we support two main protocols: OpenID Connect (an extension to OAuth 2.0) and SAML 2.0.

OpenID Connect​

OpenID Connect (OIDC) is an authentication protocol that is an extension of OAuth 2.0. While OAuth 2.0 is a framework for building authorization protocols, OIDC is a full-fledged authentication and authorization protocol. OIDC uses Json Web Token (JWT) set of standards. These standards define an identity token JSON format and ways to digitally sign and encrypt data in a compact and web-friendly way.

There are two types of use cases when using OIDC. The first is when myDevices application asks the Identity Provider (IdP) service to authenticate a user for them. After a successful login, the myDevices application will receive an identity token (id_token) and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the IdP and contains access information (such as user role mappings) that the myDevices application can use to determine what resources the user is allowed to access.

The second type of use cases is that of a client that wants to gain access to myDevices services. In this case, the client asks myDevices' Identity Provider to obtain an access token it can use to invoke on other remote services on behalf of the user. myDevices authenticates the user then asks the user for consent to grant access to the client requesting it. See our Admin or Cloud API for more information.

SAML 2.0​

SAML 2.0 is a similar specification to OIDC, but older and more mature. It has its roots in SOAP and the a lot of WS-* specifications, so it tends to be a bit more verbose than OIDC. SAML 2.0 is primarily an authentication protocol that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption are used to verify requests and responses.

There is really one type of use case when using SAML within myDevices. An application such as myDevices' PWA asks the SAML 2.0 Provider to authenticate a user for them. After a successful login, the myDevices's application will receive an XML document that contains something called a SAML assertion that specifies various attributes about the user. This XML document is digitally signed by the realm and contains access information.

OpenID Connect (OIDC) vs. SAML​

Picking between OpenID Connect and SAML depends on your Identity Provider compatability and support. SAML is a more mature protocol choosen over the newer OIDC. In most cases, myDevices recommends OIDC due to the wider community support and compatibility and SAML seems to be more verbose. For example, OIDC is more suited for Web applications because it is easier to implement on the client side than SAML.