Getting Started
Introduction
Thank you for choosing SSOfy, your collaborative partner in advanced single sign-on authentication solutions.
SSOfy is highly customizable and can be tailored to fit the specific needs of your application stack. Its flexibility enables developers to easily integrate it into their existing systems, reducing the time and resources required for implementation.
We always update the product with new features and security patches to ensure that your application stack remains protected against the latest threats.
APIs are based on simple HTTP/JSON calls, allowing for the seamless integration of a wide range of application stacks, including those built on different technologies and programming languages.
If you need to know what single sign-on is, here is a cursory look at Wikipedia.
Single sign-on (Wikipedia)
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.
True single sign-on allows the user to log in once and access services without re-entering authentication factors.
It should not be confused with same-sign on (Directory Server Authentication), often accomplished by using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers.[1][2]
A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.[3]
For clarity, a distinction is made between Directory Server Authentication (same-sign on) and single sign-on: Directory Server Authentication refers to systems requiring authentication for each application but using the same credentials from a directory server, whereas single sign-on refers to systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications.
Conversely, single sign-off or single log-out (SLO) is the property whereby a single action of signing out terminates access to multiple software systems.
As different applications and resources support different authentication mechanisms, single sign-on must internally store the credentials used for initial authentication and translate them to the credentials required for the different mechanisms.
Other shared authentication schemes, such as OpenID and OpenID Connect, offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled.[4] An increasing number of federated social logons, like Facebook Connect, do require the user to enter consent choices upon first registration with a new resource, and so are not always single sign-on in the strictest sense.
Quick Start
Our Quick Start guide can assist you in moving through the development process quickly — if you lack the time or the patience to study the docs one at a time.
Terms and Definitions
You must become familiar with a few terms before start reading the documents,
| Term | Description |
|---|---|
| Client Application | The application or website that initiates the user's login. Typically, this is your Frontend software. This should not be confused with the OAuth2 term Client. |
| Resource Server | Also known as API Server, This is your own backend service that will serve data to SSOfy and verify authentications. |
| Resource Owner | Refers to the user in your system. |
| Client Library | Connecting to and accessing an OAuth2-based login page requires a series of evaluations and is not the same as simply opening a url. A Client Library is required to initiate the process. |
| Login Server | This is the service that SSOfy runs for you. The server is in charge of rendering the login page, handling authorization, and generating and maintaining access tokens. |
How SSOfy works
SSOfy provides a no-store authorization and authentication server based on OAuth2 standards and doesn't keep any sensitive information internally, such as user data and credentials. Instead, the credentials will be verified by your own server and the necessary data will be queried securely from the resource server (your API Server) whenever needed, so you have to also maintain your servers' availability side by side as they actively interact with SSOfy platform and your users.
SSOfy generates and maintains access tokens which should be verified on your backend (usually through middleware).
An example view of the login process when paired with SSOfy is demonstrated in the following diagram.
Single Log Out (SLO)
SSOfy allows users to log out of the current session or all devices used to sign in previously. All tokens created during the session will be invalidated. While token invalidation on demand is theoretically not possible with JWT, SSOfy provides a hybrid workaround in which the tokens can be validated online. Verification is accomplished by making an API call to SSOfy, and the result is cached until the token deletion event is received via the webhook.
Read more about the events and the payload structure here.
SDK
Although it is not required, SSOfy also offers official SDKs for a number of programming languages and frameworks and encourages best practices for effectively interacting with SSOfy servers.
SDKs offered by SSOfy should not be confused with OAuth2 Client libraries. Although certain SDKs may also offer some limited built-in support for OAuth2 Client workflows, the major focus of the official SDKs will be to utilize SSOfy APIs for operations like token verification or gathering user information.
Knowledge BaseDo you need support?
Copyright © 2024 Cubelet Ltd. All rights reserved.