Single Sign-On (SSO)

Single Sign-On (SSO) is an authentication method that enables users to securely authenticate with multiple applications using a single set of credentials. It is commonly used as a way for Internet users to login or register for a new website via their existing account on a different website, without having to expose their password credentials between the two websites.

The TechChange platform supports Single Sign-On via an implementation of the OAuth 2.0 Authorization Framework.

The OAuth 2.0 authorization framework introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth 2.0, the client requests access to resources that are controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner's credentials directly to access the protected resources, the client obtains an access token from the authorization server via approval from the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

For more information on the OAuth 2.0 authorization framework, see here.

Social Network Integration

The TechChange platform can support Single Sign-On via integrations with the following Social Network Providers:

• Google
• LinkedIn

Google

As an administrator, you can choose to enable or disable Single Sign-On via Google for your TechChange organization. By default, Single Sign-On via Google will be disabled for your TechChange organization.

In order to control Single Sign-On via Google:

1. Navigate to the homepage of the Admin Portal.
2. Click the Settings button.
3. Select the Integrations menu item.
4. Use the button to enable or disable Single Sign-On via Google.

LinkedIn

As an administrator, you can choose to enable or disable Single Sign-On via LinkedIn for your TechChange organization. By default, Single Sign-On via LinkedIn will be disabled for your TechChange organization.

In order to control Single Sign-On via LinkedIn:

1. Navigate to the homepage of the Admin Portal.
2. Click the Settings button.
3. Select the Integrations menu item.
4. Use the button to enable or disable Single Sign-On via LinkedIn.

Custom 3rd-Party Integration

The TechChange platform can support Single Sign-On via a custom integration with your 3rd-party authentication/authorization system.

General Requirements

TechChange is responsible for the implementation of an OAuth 2.0 confidential client.

The 3rd-party is responsible for the implementation of an OAuth 2.0 authorization server and resource server.

TechChange will provide you with the following information:

1. The TechChange client type will always be a confidential client, i.e. the TechChange front-end web application and back-end APIs.
2. The TechChange client authorization grant type, i.e. authorization_code.
3. The TechChange client redirection URI, i.e. https://identity.techchange.org/api/v2/oauth/callback.
4. The TechChange client name, description, logo, etc. required for branding purposes.

You will provide TechChange with the following information:

1. client_id => A unique client identifier.
2. client_secret => The client credentials password used for authenticating with the authorization server.
3. auth_endpoint_uri => The authorization endpoint used to interact with the resource owner and obtain an authorization grant via the HTTP GET method.
4. token_endpoint_uri => The token endpoint used by the client to obtain an access token by presenting its authorization grant or refresh token via the HTTP POST method.
5. user_resource_uri => The resource endpoint used to fetch the 3rd-party user data via the HTTP GET method and which is required to create a new user or login an existing user on the TechChange platform. The resource endpoint must return the following information about the user (at minimum):

{
    "email": "bob-smith@techchange.org",
    "first_name": "Bob",
    "last_name": "Smith"
}

Security Requirements

TechChange requires that the 3rd-party authorization and resource server implement the following security measures:

1. The Authorization Server MUST require the use of TLS for any requests involving the user's password, client password, access tokens, refresh tokens, or authorization grants and MUST protect any endpoint utilizing passwords against brute force attacks.
2. The Authorization Server MUST include the state value provided by the TechChange client in the authorization grant response when redirecting the user-agent back to the TechChange client. The state is an opaque value used by the client to maintain state between the request and callback. The parameter is used for preventing cross-site request forgery.
3. Access token and refresh token credentials MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the TechChange client to whom the access token is issued.
4. The Authorization Server MUST register the redirection endpoint(s) for the client. If an authorization request fails due to a missing, invalid, or mismatching redirection URI, the Authorization Server MUST NOT automatically redirect the user-agent to the dangerous redirection URI.
5. The Authorization Server MUST ensure that the redirect URI used to obtain the authorization code is identical to the redirect URI when exchanging the authorization code for an access token.
6. The Authorization Server SHOULD provide access tokens with the minimal scope necessary for Single Sign-On to work, i.e. only access to the user_resource_uri endpoint.
7. The Authorization Server should attempt to educate end-users about the risks phishing attacks pose and should provide mechanisms that make it easy for end-users to confirm the authenticity of their sites.