Managing SSO Login for OAuth on the Platform

If you are using OAuth on the platform, you'll need to make sure that the resource owner authenticates so that you can get the needed permission to access resources.

The documentation for the login and SSO login operations for OAuth doesn't include parameters. This is because the parameters are determined by the domain of the user being authenticated.

There are two classes of domains:

  1. Domains for which the platform collects the credentials and presents them to the domain’s login process manager to authenticate the user. siteusers is a domain reserved by the Community Manager developer portal for platform users of this type.
  2. Domains for which the platform redirects the user to an identity provider's URL, to authenticate with the identity provider and obtain an SSO token which we use to authenticate. The SSO token parameters are based on the domain of the user being authenticated. For this reason, no parameters are listed for this type of domain.

For type 1 above, the platform collects the credentials and gives them to the login process manager.

Convention:

  • Identity parameters start with identity_.
  • Secret parameters start with secret_.

For example, the siteusers domain supports identity_email and secret_password to indicate that email address is the identity parameter, whereas password is the secret parameter. For LDAP domains, depending on how the LDAP domain is configured, the platform can support either email address or username as the identity parameter. In the default settings (only the one with UI), the identity_username parameter is for the identity parameter and the secret_password parameter is for the secret parameter.

For type 2 above, the platform doesn't have conventions, since the specification that the domain follows defines the parameter names. For example:

  • An OpenID Connect Relying Party domain could use code, access_token or id_token parameters as SSO token (or a source of SSO token).
  • A SAML web SSO service provider domain supports an assertion parameter.
  • In some cases, the SSO token might not be a parameter; instead, it could be a cookie. For example, a SiteMinder domain might use an SMSESSION cookie as the auth token.