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.
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.
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. 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.
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.
You must become familiar with a few terms before start reading the documents,
|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.
|Also known as API Server, This is your own backend service that will serve data to SSOfy and verify authentications.
|Refers to the user in your system.
|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.
|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.
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.
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.
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.