User sign-in :: Authway Docs

Authentication of the user must be performed by the Identity Provider (IdP) (in this case by Authway), where the user´s session or credentials will be checked. It is an application that wants to authenticate the user, that triggers the sign-in flow by using either the OpenId Connect protocol (OIDC) (preferred) or the SAML protocol (only available in Enterprise Edition and less preferred, but sometimes necessary). The application is called Client in OIDC and Service Provider (SP) in SAML. The authentication is done by a web browser, running on the user´s device, by redirecting the user to the IdP. How the users are authenticated is left up to the IdP to decide (even if the application can pass parameters affecting how that decision is done).

Considerations for different kind of applications

A server-based web application can choose to use OIDC or SAML.

Mobile applications running on platforms such as iOS and/or Android should use the system browser to re-direct the user for authentication. Embedded web views are not trusted, since there is nothing that prevents the app from snooping on the user password. User authentication must always be done in a trusted context that is separate from the app.

Single Page Applications (SPA) or other browser (JavaScript) applications should carefully choose how to handle authentication and we have a separate page with more details about this.

Choose OpenId Connect Flow

OIDC has flows designed for the different application types.

Authorization code flow: This is the most used and the preferred flow, primarly used by server-base applications and native/mobile apps. Authentication is triggered by re-directing the user to the IdP, but when the user is returned only a code is passed back to the application through the user browser, never any token(s). Instead, the tokens are fetched by using a back-channel where the code is exchanged for the token(s). This is the most secure flow since the tokens are never exposed to the browser and it also makes it easy to authenticate the application (client). If possible, it also good to use this flow with PKCE.
Implicit flow: Can be used by SPA or other JavaScript applications that don’t have a backend. Token(s) are send directly to the browser during re-direction of the user after a successful sign-in. Therefor this flow is less secure and as detailed in our article you should consider to use a Backend for Frontend (BFF).
Hybrid flow: Rarely used nowdays and it is a combination of implicit and code flow.

SAML Authentication

Authway supports SAML authentication in the Enterprise edition, but is must be actively turned on by IRM. Authway supports both Redirect and Post Bindings.