An identity provider (IdP) authenticates people for an application, letting the application rely on a separate, trusted service instead of collecting and storing every user password itself. This can reduce the security burden of credential storage, but it also makes the sign-in integration a security boundary: the application must accept identity data only through the provider’s intended flow. section 8.17 section 8.3
OAuth is generally for authorization: granting an application permission to access something. OpenID Connect adds an authentication layer to OAuth. After a user signs in, the calling application receives a digitally signed JSON Web Token (JWT) containing profile information such as an email address. The application can use that information to identify the user, provided it follows the provider’s integration requirements. section 8.3
A practical identity-provider integration usually requires the application to:
- Register with the chosen provider and obtain an access token identifying the application for OAuth calls. section 8.3
- Validate the redirect or callback request, extract the returned credentials, and locate or create the corresponding local user. section 8.3
- Request the profile data needed for sign-in, such as an email address, and handle a user declining that permission. section 8.3
- Choose supported providers deliberately rather than adding an excessive number of login options. section 8.3
OpenID Connect sign-in
A “Log in with Facebook” action sends the user to Facebook. On the return redirect, the application validates the request, reads the authentication data, checks that an email address was supplied, finds a user through the OAuth data, signs in a persisted user, and otherwise redirects to registration. The same pattern keeps the application focused on its local session and user record while the provider performs authentication. section 8.3
<%= link_to facebook_omniauth_authorize_path(
next: params[:next]), method: :post %>
<div class="login">Log in with Facebook</div>
<% end %>
This minimal template action illustrates the user-facing start of a provider-managed sign-in flow: a login button posts to the Facebook authorization route and preserves a next-page parameter. section 8.3
SAML serves a similar sign-in purpose in organizations that operate their own identity-provider software, often alongside LDAP directories such as Microsoft Active Directory. The web application is the SAML service provider (SP). It publishes XML metadata describing its Assertion Consumer Service (ACS) callback URL and the certificate the identity provider uses to sign requests; after sign-in, the provider sends the user to that ACS endpoint. section 8.4
For an organization, central authentication can make offboarding simpler: access to connected systems can be revoked when an employee leaves, and employees do not enter their directory passwords directly into every web application. SAML integration is described as more complicated than OAuth integration, so treat its metadata, callback endpoint, and signing certificate as configuration that must match the identity provider. section 8.4
