Thine - Responsive Modern HTML Template
Simple Safe Quick
  • Slide
  • Slide
  • Slide
  • Slide


How it works

Try it for free

An SSQ signon authorization server can:

  • Register and manage applications (apps)

    that will use the authorizaton server to issue access tokens. You may register 3 types of apps:
    • a Master app

      This will usually be the first or main app in your ecosystem. It will show some kind of login dialog to the user, and serve as a hub for your Slave apps to log in with.
      Once a Master app obtains the user's credentials (e.g. a username and password) it will swap them for an access token.
      SSQ signon will make no assumptions about the username or password, they can be e.g. an e-mail address, a number, text in any format, or even null if that is your valid scenario.
      Since Master apps process the user's credentials (e.g. a password) they should be developed internally or by a trusted entity.
    • a Slave app

      Will sign the user in by making a Single Sign On request to a Master app.
    • an Auto app

      swaps it's id and secert for an access token.
      In this case the generated access token will contain a constant, preconfigured user id and scope (intended e.g. for non-human users).
  • Issue access tokens

    to your app's users. An access token will typically contain the user's identity and a scope. Thus, when your app receives such an access token, it's sender can be authenticated (i.e. you can tell who it is) and authorized (i.e. you can use the scope to tell what he/she can or cannot currently do). Think of an access token as of a "swipe card", that will allow the user to open certain "doors" within your app.
  • Validate access tokens

    Your authorization server, when requested, will make sure that a given access token is correct, has not expired and was not counterfeited, and if so will return the user's identity and scope contained inside the token. A safe application should validate each and every access token it receives.
  • Build safe redirect URIs for Single Sign On

    Single Sign On is a design pattern where one or more "Slave" apps use one "Master" app to authenticate and authorize their users. This process requires carrying the users identity and scope over from the Master app to the Slave app. Obviously, simply carrying an access token between the two would expose it to third party servers, plugins, scripts, other applications and the end user him(her)self, making it vulnerable to hijacking. For this reason SSQ signon can build a special safe redirect URI to your Slave app. The safe redirect URI will typically include a short-lived authorization code that only your Slave app can swap for the user's access token. Think of the authorization code as of means to safely transmit the users credentials between your apps, while the sensitive access tokens remain in the safety of their local storages.
  • Issue refresh tokens

    along with access tokens for a specific app. Refresh tokens typically have a long lifetime, and can be used to issue a new access token when the current one expires. Think of a refresh token as of means to implement the "remeber me" checkbox in your standard login dialog. Refresh tokens cannot be issued for Auto apps.
  • Revoke access tokens

    Your authorization server can be configured to accept requests that will revoke all (access & refresh) tokens for a given user identity. You may find this useful when blocking or deleting user accounts, or when a user's permission level has changed.

SSQ signon comes with examples

Knowing the power of learning by doing that lies within "copy-paste", we have prepared and will expand an array of tools and examples to make integrating SSQ signon into your systems super-easy. Each example includes:

  • A Master app that will use SSQ signon to protect access to some of it's resources, and allow users to gain access with a username and password.
  • A Slave app that will use SSQ signon to protect access to some of it's resources and allow users to gain access by Single Sign On with the Master app.
  • An example HTTP users endpoint microservice, which provides a (hardcoded) users database when connected to a SSQ singon module.
Currently the examples are implemented with the following technology stacks:
  • ASP.Net MVC (C#) (servers) + Angular.js (clients)
  • Node.js (servers) + Angular.js (clients)
  • Node.js (servers) + jQuery (clients)
Usage instructions & detailed information about the examples are provided in the github readme file. Check out the demos section to see one of the examples deployed and running.

SSQ signon works over a REST API

We do provide some tools along with the examples to enable integrating with SSQ signon with just a few (ideally - 1) lines of code. However, in the end all you need to integrate with SSQ signon is an HTTP client.

SSQ signon uses your users database

An SSQ singon authorization server is not meant to store any user records by itself. However, issuing, refreshing and revoking access tokens will obviously require querying a users database at some point. To do this, every SSQ signon module utilizes a user endpoint. Currently, 2 types of user endpoints are supported:

  • an HTTPS user endpoint

    An HTTPS service, which SSQ signon can reach over the public internet. This service should provide 2 HTTPS endpoints (they may also be the same, one endpoint):
    • Authenticate and authorize - will query your desired users database, and return the users id and scope when given a correct username and password.
    • Reauthorize - will query your desired users database, and return the users id and scope when given a correct username (used when the user has already been authenticated).
    An HTTPS users endpoint must be secured with either Basic HTTP authentication or NTLM authentication to make sure no unauthorized parties can use it. For detailed requirements on the HTTPS users endpoint please refer to the API documentation.
  • a Dummy user endpoint

    An embedded database that can store up to 10 "users" ([username, password, scope] tuples). Use it during trials or development. The dummy user endpoint is not intended for production use!

SSQ signon module settings

The settings section of every SSQ signon module is divided into these subsections:

  • Allowed origins - When deploying web browser based client applications that will make AJAX HTTPS requests directly to the ssqsignon.com API, CORS must be taken into consideration. Your SSQ singon module will only allow requests from web pages running under URL addresses listed on the allowed origins list. For users not familiar with CORS: this is a browser only restriction. It will not apply to HTTPS requests that did not originate in a web browser.
  • Dummy users endpoint - Configure the user accounts served by the dummy user endpoint here. You may add up to 10 dummy user accounts.
  • HTTPS users endpoint - Configure the HTTPS users endpoint here. The endpoint must support either Basic authentication or NTLM authentication.
  • Automatic token revoking - When this feature is enabled, you may make requests to SSQ signon's token nullification endpoint to revoke access tokens for a given user identity. See the API documentation on token nullification endpoint for usage details.

Best practices while using SSQ signon.

Once you've registered with SSQ signon and created your first module, check the best practices section of the module admin app for useful hints on how to get the most safety, performance and value out of your new authorization server.