Sorry, you need to enable JavaScript to visit this website.


Your feedback is important to keep improving our website and offer you a more reliable experience.


gSSO or ‘glib-Single-Sign-On’ is an extensible, secure storage and a single sign-on service for Linux-based platforms. Its password and authentication management supports all the common authentication protocols, like OAuth, Digest and SASL out of the box. gSSO is extensible, based on a plug-in architecture.

These are the high level requirements for the framework.

Service provider's point of view

Strong passwords

Enable users to use a strong password by not requiring them to enter the password frequently. It's also possible to automate password generation, so users don’t have to remember passwords at all.

Strong authentication methods

Strong authentication methods should be used to verify the user, application, and user's consent for the application to access their data.

Credential access control

Only explicitly allowed applications can access the stored credentials.

Authorization support

Whenever necessary, it must be possible for an application or authentication server to trigger a secure authorization dialog with a custom message to the user. The user may be required to enter their credentials for authorization or user verification purposes. Even if the original action was requested by an application, it must not be possible for the application to forge the message triggered by the server. When necessary, it must be possible to display CAPTCHA-images, as part of the user authorization.

Display of custom elements on request

The application or authentication server must be able to trigger custom messages requesting acceptance from the user, such as updates to the terms of service (TOS).

Service credential registration

It must be possible to implement service-side credential creation/registration from an application. This can be used to create new service-side accounts, or change credentials of an existing account.

Custom information

It should be possible to associate custom information, such as billing information with stored credentials.

Access scope

The entity storing the credentials must be able to specify the methods and realms the credential can be used for.

Secret validation

It must be possible to validate the correctness or availability of the identity information, including the secret, locally or remotely, before storing the identity.

User's point of view

Sharing credentials

The user should have to enter his credentials only once per service side account, unless specific user authorization is needed for the application.

Credential safety

Credentials should be stored such that a third party cannot access or use the stored credentials, in case the device is lost or stolen. Even in case where the attacker is attempting to directly connect and manipulate the physical storage device.

Credential cleanup

It must be possible to safely erase the stored credentials, in case the user wants to sell or give away his device. This operation must be able to be performed by service point and should be able to be performed by the user remotely. It must not be possible for the new device owner to access credentials removed in such a way.

Credential selection

The user should be able to select a credential from a set of applicable ones, whenever necessary.

Credential storage

The user must be able to securely store their credentials. The user must also be able to decide whether a secret is stored, or just an identity.

Secret caching

In the case where a secret is not stored, it must be cached as long as active sessions exist or until sign-out is explicitly triggered. The secret must be prompted from the user only once, even if multiple applications are using the identity.

Hardware back-ends

It must be possible to interface to hardware backed methods through the client API.

Secret change

It must be possible for the user to change his secret. Whenever the secret has been changed at the service side, the user must be prompted for a new one in a secure way. The user must be prompted only once per secret change, per identity, even if multiple applications are using the same identity.

Identity management

The user should be able to see, modify, and delete the stored identities. The user should be also able to authorize and de-authorize applications and/or application groups to use the identity.


The user must be able to securely back up the stored identities. It must be also possible for the user to restore the backup on a new device.

Device point of view

Access control

Malicious or unauthorized applications must not have access to the user’s secrets.

Secure user interface

It must not be possible for third party application to self-authorize any operations that need the user’s authorization. Malicious applications should not be able to fake or otherwise misrepresent the dialogs requesting user’s authorization.

Battery lifetime

Network usage must be minimized, for example by caching valid authentication tokens. Whenever an application is closed and restarted, it must be able to re-acquire the previous, still valid authentication token.

Access control

The framework must be able to determine whether the calling application has the right to perform the requested operation with the stored identity.

Application point of view


The application must be able to request authentication using the stored secret. The application should be able to perform this without retrieving the secret. Well known, standard internet protocols or methods should be supported by the framework. The application must be able to use these protocols or methods without having to re-implement them.


Standard PKI operations must be supported using stored keys, without retrieving the keys to the application.

Token renewal

Whenever the application requests an authentication token, the framework must renew the token automatically, if it has become invalid.

User prompts

Whenever it is necessary to prompt the user for actions related to the request issued by an application, any required user interaction must happen transparently from the application’s point of view. It must be possible to make this prompt modal to the calling. It should be possible to embed the prompt to the calling application.

Identity storage

The storage must guarantee integrity and security of the stored secrets to the overall level of the platform. Whenever a hardware platform supports security features, those should be used for the secret storage implementation.


It must be possible to store and retrieve standard X.509 certificates. Standard envelopes, such as PKCS#7,8,12, must be supported. It must be possible to limit access scope of the stored certificates by user, application, or application group.