Integration Patterns

To integrate sgID into your application, you need to understand the different OAuth 2.0 flows based on industry standards. The most popular flows are the Authorization grant flow (for confidential clients), Implicit flow (for public clients), and Hybrid flow (for public clients). However, sgID only supports confidential clients at this time due to its privacy-preserving nature.

What are public clients?

Public clients, such as standalone SPA or native mobile apps, cannot keep a secret because their source code can easily be inspected to reveal secrets or credentials. As such, any client authentication becomes irrelevant. The OAuth / OIDC configuration for public clients is completely public and exposed when generating the authorization URL, making it easy to impersonate these clients.

What are confidential clients?

Confidential clients, on the other hand, can maintain the confidentiality of their credentials or use other secure client authentication methods. They consist of two components: a frontend app (which can be a single-page application, native mobile app, or server-side rendered frontend) and a backend server that communicates with the sgID server.

What does this mean for sgID?

Since SPAs or mobile apps cannot keep secrets, they cannot be trusted to communicate with the sgID authorization server. Therefore, all communication between the client and sgID must go through the backend server, and the frontend component is not considered an OAuth client.

Due to sgID's privacy preserving nature, private key is required to decrypt user information. Hence, at this juncture, sgID only supports confidential client.

In this documentation, we will discuss three integration patterns: Web Server and SSR Front-End, Back-End for SPA Front-End (BFF), and Back-End for Native Mobile Application. These integration patterns will help you implement the OAuth 2.0 flows and integrate sgID into your application while ensuring confidentiality and security.