Mobile Identity Connect

Introduction

Mobile Identity Connect (MIC) is a service that bridges mobile applications with existing enterprise identity and single sign-on solutions. MIC enables mobile applications to integrate with a variety of identity solutions using a single OAuth2-based interface. This allows enterprise application developers to avoid the complexity of integrating these protocols into mobile, while providing enterprise IT the means to ensure that access to resources is secured only to authenticated users, as well as maintaining full control over a mobile user's identity.

Core Concepts

Mobile Identity Connect Architecture

Mobile Identity Connect Architecture

Mobile Identity Connect (MIC) is the authentication layer for connecting to mobile identity systems. It uses OAuth2 as its underlying identity protocol for connecting client applications. A client application uses OAuth to authenticate with the Kinvey Authentication Service. The service provides a login page or redirects to an existing SSO login page, allowing the client user to authenticate.

MIC's architecture enables multi-factor authentication (MFA) for mobile clients during the authentication process by exposing MFA controls through the login page.

Once authenticated, MIC retrieves a token from the underlying identity provider, encrypts it, and securely stores it for use in all future requests to access enterprise resources through Data Link connectors. A Mobile Identity Connect access token is returned to the client, along with an (optional) refresh token.

The client exchanges this token for a Kinvey session token. The Kinvey Cloud Service (KCS) then validates this token with MIC for all future requests from that session token. User credentials are not stored on the device and are never passed directly to KCS.

MIC maintains an internal time-to-live (TTL) for OAuth tokens which is configured via the Kinvey management console. MIC will re-authenticate the user after the TTL expires which will cause the underlying authentication system to be asked to obtain any tokens again. The TTL should be configured to match the lifetime of the internal authentication.

Mobile Identity Connect Architecture with Auth Link Connector

Mobile Identity Connect Architecture

Mobile Identity Connect offers many out of the box integrations, but when one is not available for your identity provider, a custom AuthLink can be created to integrate with a host of custom identity systems, such as SSO cookies, database-based authentication, or authentication against a line of business application.

The custom auth link connector sits between Kinvey and internal authentication systems. The adaptor is responsible for verifying the credentials provided from MIC against one or more internal enterprise authentication systems. The adaptor is also responsible for obtaining any internal enterprise authentication tokens, such as SSO cookies, SAML assertions, OAuth tokens, or session tokens. Tokens passed back to MIC will be stored in the encrypted MIC vault and provided to Kinvey Data Link Connectors during normal Kinvey request processing.

All links controlled by Kinvey are encrypted using TLS. Links not controlled by Kinvey are expected to use TLS encryption for production deployments.

Keep in mind that SSO Providers often store their own session data in cookies and logging out from Kinvey will clear Kinvey's session and refresh tokens from the local device, and cause subsequent requests that use these tokens to fail with a 401 Unauthorized response. However, SSO providers may independently retain their sessions via cookies, enabling a user to log into the Kinvey app again through SSO without re-entering their password.

For instance, using Ping Identity with SAML-Redirect, the user will remain authenticated on Ping Identity website after logging out from the associated Kinvey application. This would enable a user to login to their Kinvey app after being logged out, i.e. if they remain logged in to Ping Identity.

Configuring an Auth Service

Mobile Identity Connect is configured through the Kinvey console..

Kinvey Console User Settings

All configuration is performed on the Auth Source tab of the Users section of the management console. To configure a connector to an Enterprise Identity Source, click the “Add Auth Service” button and fill in the required fields.

SAML

Mobile Identity Connect supports SAML SP initiated SSO via POST-POST and Redirect-Post Bindings. Mobile Identity Connect does not support IdP-initiated SSO.

Configuring Kinvey

Configure SAML

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to SAML-Redirect or SAML-POST based on your IdP requirements.Yes
Provider URIThe single sign-on service URL provided by the SAML Identity ProviderYes
Redirect URI'sThe OAuth 2.0 redirect URI - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
Logout URIThe Logout URI provided by the SAML Identity ProviderYes
CertificateThe X.509 Certificate text provided by the SAML Identity ProviderYes
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLThe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

Users of Ping Identity's PingOne service should use the "Initiate Single Sign-On (SSO) URL" that is provided by PingOne when adding Kinvey as an application.

Configuring your SAML Identity Provider to accept Kinvey Requests

When configuring the SAML-Based SSO Identity Provider (IdP), the following information should be used. (note: if you are running a dedicated instance of Kinvey, replace auth.kinvey.com with the URI of your MIC instance. Contact Kinvey Support if you do not know the URI of your instance).

FieldDescriptionValue
entityIdThe unique SAML entityID for MIC.kinvey-mobile-identity-connect
Metadata URIThe signle sign-on service URL provided by the SAML Identity Providerhttps://auth.kinvey.com/saml/metadata
Assertion Consumer ServiceThe SAML Assertion URI where SAML assertions will be passed to MIC by the IdPhttps://auth.kinvey.com/saml/assertion/
Logout URLThe SAML logout URIhttps://auth.kinvey.com/saml/logout
Name ID FormatThe format that Kinvey expects for the auth identifying NameIDurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Users of Ping Identity's PingOne service can find a pre-configured link to Kinvey's Moble Identity Connect in the application catalog by searching for "Kinvey".

Kinvey does not directly support SSO Single Logout. The SAML identity provider should be accessed manually if single logout is required.

SAML Assertion Attributes

Kinvey supports the passing of SAML assertions to enterprise data sources through Data Link Connectors. Depending on the security requirements of your organization, different SAML attributes may be required for authorization purposes by your data sources. Mobile Identity Connect is configured to accept any attributes in the SAML assertion, and passes them through to any Data Link Connectors as-is.

OAuth2

Mobile Identity Connect supports Authorization Code and Resource Owner Password Credentials Authorization Grant credential types. See your OAuth2 provider administrator or Section 1.3 of the OAuth2 specification for more details.

Configuring Kinvey

Configure OAuth2

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to OAuth2Yes
Provider URIThe token endpoint provided by the OAuth2 ProviderYes
Redirect URI'sThe OAuth 2.0 redirect URI to be used by the client app - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
Grant TypeThe OAuth2 Grant Type to be requested. Authorization Code and Resource Owner Password Credentials are supported.Yes
Grant EndpointThe OAuth 2.0 authorization grant endpoint provided by the OAuth2 providerYes
Client IdThe client id supplied by the OAuth2 providerYes
Client SecretThe client secret supplied by the OAuth2 providerYes
User Id AttributeThe attribute to be used to obtain the userId. If no User Id endpoint is supplied, the service will look for the specified attribute in the id_token attribute of the token response. If a User Id endpoint is supplied, a request will be made to that endpoint and the user id will be obtained from the specified attribute.Yes
User Id EndpointAn endpoint from which to obtain the user id, found in many OAuth2 implementationsNo
ScopeAny scope attributes as defined by the OAuth2 providerNo
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLThe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

Configuring your OAuth2 Identity Provider to accept Kinvey Requests

When configuring the OAuth2-Based SSO Identity Provider, the following information should be used. (note: if you are running a dedicated instance of Kinvey, replace auth.kinvey.com with the URI of your MIC instance. Contact Kinvey Support if you do not know the URI of your instance).

FieldDescriptionValue
Redirect UriThe URI to which the grant code will be sent.https://auth.kinvey.com/oauth2/redirect

In addition, you should obtain a client id, client secret, authorization grant endpoint, and token endpoint from the administrator of your OAuth2 provider, along with the location of the userId attirbute. Note that the userId endpoint response must be in JSON format. If the uri for the endpoint requires an argument to use JSON, this should be included here.

OpenID Connect

Configuring Kinvey

Configure OpenID Connect

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to OpenID ConnectYes
Provider URIThe token endpoint provided by the OpenID Connect ProviderYes
Redirect URI'sThe OAuth 2.0 redirect URI to be used by the client app - this should be configured to a Callback URI that will be used to pass the OAuth 2.0 GrantYes
Grant EndpointThe authorization grant endpoint provided by the OpenID Connect providerYes
Client IdThe client id supplied by the OpenID Connect providerYes
Client SecretThe client secret supplied by the OpenID Connect providerYes
Issuer IdentifierThe issuer identifier supplied by the OpenID Connect providerYes
ScopeAny scope attributes as defined by the OpenID Connect provider. Include multiple scopes by inserting a space between each scope. You can include both OpenID Connect specific scopes (profile, email, address, phone) and custom scopes.No
Do not customize the login experienceDo not use any customization for the OpenID Connect login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OpenID Connect login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth 2.0 grant is valid to obtain an OAuth 2.0 tokenNo
Token TTLThe time (in seconds) that an OAuth 2.0 token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth 2.0 refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth 2.0 refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

Configuring your OpenID Connect Identity Provider to accept Kinvey Requests

When configuring the OpenID Connect SSO Identity Provider, the following information should be used. (note: if you are running a dedicated instance of Kinvey, replace auth.kinvey.com with the URI of your MIC instance. Contact Kinvey Support if you do not know the URI of your instance).

FieldDescriptionValue
Redirect UriThe URI to which the grant code will be sent.https://auth.kinvey.com/oidc/redirect

In addition, you should obtain a client id, client secret, authorization grant endpoint, token endpoint and issuer identifier from the administrator of your OpenID Connect provider.

Active Directory

Configure Active Directory

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to Active DirectoryYes
Provider URIThe Active Directory URIYes
Redirect URI'sThe OAuth 2.0 redirect URI - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
Base DNThe Active Directory base DNYes
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLThe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

LDAP

Configure LDAP

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to LDAPYes
Provider URIThe LDAP URIYes
Redirect URI'sThe OAuth 2.0 redirect URI - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLThe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

SAML-WRAP

Configure WRAPv0.9

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to SAML-WRAPYes
Provider URIThe URI of the WRAP APIYes
Redirect URI'sThe OAuth 2.0 redirect URI - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
WRAP ScopeThe requested scope as provided by your IdPYes
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLThe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

Custom Authlink

Configure Custom Auth Link

In the Kinvey console Auth Service configuration, the following fields should be filled in:

FieldDescriptionRequired?
Type of ProviderAuth service to use, set this to CustomYes
Provider URIThe URI of the Auth Link ConnectorYes
Redirect URI'sThe OAuth 2.0 redirect URI - this should be configured to a Callback URI that will be used to pass the OAuth GrantYes
Do not customize the login experienceDo not use any customization for the OAuth login pageNo
Use a custom CSS stylesheet for the login pageUse a CSS file to customize the look-and-feel of the OAuth login page (specify the URL of the stylesheet)No
Use a custom login page that I will hostUse a login page hosted outside of Kinvey for the login page (specify the URL of the hosted login page)No
Grant TTLThe time (in seconds) that an OAuth grant is valid to obtain an OAuth tokenNo
Token TTLTHe time (in seconds) that an OAuth token is accepted before requiring a new login or refreshNo
Allow Refresh TokensEnable OAuth refresh token supportNo
Refresh Token TTLThe time (in seconds) that an OAuth refresh token is acceptedNo
Allowed AttributesSee the section on attributes and mappingsYes
Data Link Header MappingsSee the section on attributes and mappingsYes

For details on building a custom AuthLink connector, see the section on Building a Custom AuthLink.

Attributes and Mappings

The Allowed Attributes and Data Link Header Mappings settings in the Kinvey Console connector configuration control how enterprise authentication tokens are sent to a data link connector. The attributes id and audience must be included in this section. Click “Add an allowed attribute, and enter the properties.

Configure Attribute Mappings

To send any of these attributes to a data link connector a Data Link Header Mapping is required. Click “Add a header mapping …” and enter client_token as the key and X-Kinvey-Auth as the value. Data link requests will have a header named X-Kinvey-Auth containing the token as a Base64 encoded string.

Authenticating with Mobile Identity Connect

Clients authenticate with Kinvey’s MIC using the OAuth 2.0 protocol. Complete documentation of the OAuth 2.0 protocol is detailed by the IETF.

Information about Refresh Tokens can be found at http://tools.ietf.org/html/rfc6749#section-1.5.

All OAuth implementations authenticate the user and return a grant code via a redirect callback URI. For native applications (Android, iOS and Xamarin) the Redirect URI can be any valid URI, record the value and use it during the normal OAuth flow. For hybrid applications (PhoneGap, etc) follow the framework guides for intercepting redirects and use the same Redirect URL as specified in the console. For web applications choose the Redirect URL where the web app listens for OAuth grants.

Authorization Grant

The authorization code grant flow of the OAuth2 spec provides a two-step authentication process. In the first step, the user is presented with a server-side login page for authentication. In Kinvey's implementation, that login page can be either provided by Mobile Identity Connect (with or without custom styling) or can be independently created and hosted, with Kinvey acting as the router to that page. The login credentials are forwarded to the underlying authentication source for authentication. Upon successful authentication, a short-lived authorization grant code is generated which can be used to create an access token.

Users requiring multi-factor authentication (MFA) support must use the authorization code grant flow configured to use the authentication providers login page.

In the case of SAML-Redirect, the login page is provided by the SAML IdP. Upon successful authentication, a callback URI is invoked with a grant code included in the query string. The grant code is then exchanged for an access token, which is used to authenticate to Kinvey, and exchanged for a Kinvey token.

Keep in mind that a SSO Provider may maintain its own session state independent of the Kinvey app, and Kinvey apps with a third-party SSO Provider configured may be accessible via the Provider site after Kinvey session tokens have been invalidated (as a new session can simply be created by way of SSO). For instance, using Ping Identity with SAML-Redirect, the user will remain authenticated on Ping Identity website after logging out from the associated Kinvey application. This would enable a user to login to their Kinvey app after being logged out, i.e. if they remain logged in to Ping Identity.

All requests to Mobile Identity Connect use the base URL of https://auth.kinvey.com/. If you are using a dedicated instance of Kinvey with a different base URL, then modify the base URL by calling:

myKinveyClient.getActiveUser().setMICHostName("https://instance-auth.kinvey.com)");.

There are three steps to use the authoriation grant login flow in your Android application.

Add an Intent-Filter to the AnroidManifest.xml

This login flow uses a Redirect URI to return data to the client after the user has been authenticated. The Android operating system will intercept the redirect and bundle it into an Intent, so that it can be recognized by native applications. First, add an <intent-filter> to the main <activity> tag in the AndroidManifest.xml. The below code snippet shows a sample Activity declaration, containing the new <intent-filter>.

In the code below, replace myredirecturi with a completely lowercase version of the scheme of the application's configured redirect URI. For example, a redirect of MyOauth:// would be entered here as myoauth.

<activity
    android:name="com.kinvey.auth.sample.Main"
    android:label="@string/app_name" 
    android:launchMode="singleInstance" >
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" /> 
        </intent-filter>


        <!-- This is the new Intent filter  -->
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="myredirecturi" />  <!-- This is the scheme which must be changed -->
        </intent-filter>

</activity>

Override onNewIntent

Android will use the intent filter to send the intent to the onNewIntent(Intent intent) method of your activity. Override this method, and pass the intent to the Kinvey Client.

@Override
public void onNewIntent(Intent intent){
    super.onNewIntent(intent);
    myKinveyClient.getActiveUser().onOAuthCallbackRecieved(intent);
}

Initiate the Login Flow

After writing the code to manage the redirect intent, use the below code snippet to initiate the login flow. The method onReadyToRender(String myURL) will be executed when the login page URL has been generated. This URL can be rendered in a webview or passed to the browser, and will provide the user with a login page. Once they have successfully logged in, the redirect URI will be used to return the necessary tokens to the client. After this, the client will automatically finish the login flow and return a fully initialized, logged-in User to the onSuccess(User user) method. If any error occurs at any point during this oauth flow, the onError(Throwable e) method will be executed with details of the exception.

UserStore.loginWithAuthorizationCodeLoginPage("myRedirectURI://", myKinveyClient, new KinveyMICCallback() {

    @Override
    public void onSuccess(User user) {
        //Logged in successfully    

    }

    @Override
    public void onFailure(Throwable error) {
        //something went wrong!            
        error.printStackTrace();                
    }

    @Override
    public void onReadyToRender(String myURLToRender) {
        //Time to render the login page for the user!
        //This renders the login page with the device's default browser
        Uri uri = Uri.parse(myURLToRender);
        Intent intent = new Intent(Intent.ACTION_VIEW, uri);
        startActivity(intent);
    }
});

Automated Authorization Grant Flow

The Automated Authorization Grant flow is a slightly modified version of the authorization grant flow, which allows the username and password to be submitted to a temporary uri rather than presenting a login page. This does not require rendering a webpage for the user to enter their credentials.

All requests to Mobile Identity Connect use the base URL of https://auth.kinvey.com/. If you are using a dedicated instance of Kinvey with a different base URL, then modify the base URL by calling:

myKinveyClient.setMICHostName("https://instance-auth.kinvey.com)");.

Initiate the Login flow

UserStore.loginWithAuthorizationCodeAPI(myUsername, myPassword, "myRedirectURI://", myKinveyClient, new KinveyUserCallback() {

    @Override
    public void onSuccess(User result) {
        //logged in successfully!
    }
    @Override
        public void onFailure(Throwable error) {
        //something went wrong!
        error.printStackTrace();        
    }
});

Building a Custom AuthLink

A custom authlink is a lightweight microservice that acts as a bridge between Mobile Identity Connect and an enterprise identity system. It can be deployed anywhere, and must implement a single HTTP endpoint (defined in the provider URI in the Kinvey console) which is invoked using an HTTP POST. If the provider URI is http://auth.example.com/a/u/th, it will be invoked as POST /a/u/th.

The payload is encoded as UTF-8 with Content-Type set to application/json. The payload contains:

{
    username: <string>,
    password: <string>
}

The adaptor is required to respond in one of two ways depending on error or success.

Error

On an error the adaptor is expected to return an HTTP status code of 401. An optional JSON body can be returned with a single property authError. The authError property can either be an object or a string.

If an object, the object must have two properties: error, and error_description. The error value must be one of the following:

  • server_error
  • access_denied
  • temporarily_unavailable

If the error does not match one of these three, server_error will be used. The error object returned to the client will be the contents of the authError object.

If authError is set to a string, then an error object will be constructed with authError.error set to server_error and the error_description set to the contents of the string.

Success

On success the adaptor is required to return an HTTP status code of 200 with a body encoded as UTF-8 with Content-Type set to application/json. The payload should contain:

{
    authenticated: true, 
    token: ""
}

where token is an arbitrary Base64 encoded string. This string should include all enterprise tokens that need to be sent to the data link connector. This object gets stored encrypted in the MIC value and is provided to data link connectors (per configured attributes and mappings).

Additional properties can be included in the response. These properties can be enabled by including them in the allowed attributes of your MIC configuration.

Error Types

The following are the possible errors that can be returned, with the corresponing reasons:

ErrorCause
invalid_grantThe Grant code being sent for the token request is invalid. This usually occurs if the request takes longer than the grant TTL configurable in the console (default 10 seconds but can be changed)
invalid_requestThe parameters that were submitted in the request from the client are invalid (e.g. incorrect redirect_uri, client_id (app Key), or client_secret (app secret).
invalid_clientThe client (app id) is invalid, or the client secret (app secret) and redirect uri are invalid for the specific client
invalid_tokenThe token is invalid. This often means that the token has expired, but can be caused by other issues (such as a token that was never valid).
server_errorA server error has occurred. This may indicate an error accessing the underlying auth source (e.g. the SAML SSO system, the OAuth system, a custom AuthLink Connector, etc).
access_deniedThe credentials submitted by the user are invalid
unauthorized_clientThe app is not authorized. (App Key and secret don't match)
unsupported_grant_typeThe grant type isn't supported by MIC. This error should never be received if using the Library methods.
invalid_scopeThe scope requested by the client is invalid.
temporarily_unavailableThe remote IdP service is temporarily unavailable.
Unknown ErrorAn unknown error. Please submit to support along with a requestId (if possible) and the date and time the error occured.
Got a question?