# Automatically detect login

# Ready to work

  1. Create an Authing Account

# Principle introduction

Automatically detecting the login status of the associated application on the same device is essentially establishing a session connection between the deviceId (device ID) and the Authing server.

After a user logs in on an application, call the Authing interface to create a session between the deviceId and the Authing server, so that when the user logs in to other applications on the same device, the existence of this session can be detected and skipped Login steps to realize automatic login.

Suppose you have three apps: App 1, App2 and App3. As long as one of the apps has established a session relationship with the Authing server, the session can be detected.

# Start access

# Get device ID

Please be sure to verify that the deviceId you get in different apps is the same when testing!

# iOS

The device ID of an iOS device can be obtained through identifierForVendor (opens new window), and the device ID obtained by the same vendor application is the same.

Under what circumstances belong to the same vendor?

  1. The application downloaded from the App Store is judged based on the application information registered in the App Store.
  2. Apps not downloaded from App Store
    1. In iOS 6 and before, apps with the same first two parts of bundle id belong to the same vendor, for example, com.example.app1 and com.example.app2 are the same vendor. com.example.app1.xxx and com.example.app2.xxx also belong to the same vendor.
    2. iOS 7 and later, applications with the same bundle id except the last part belong to the same vendor, for example, com.example.app1 and com.example.app2 are the same vendor. But com.example.app1.xxx and com.example.app2.xxx do not belong to the same vendor.

If your application does not belong to the same vendor, it is recommended to use ASIdentifierManager (opens new window).

Swift 5 code example:

let deviceId = UIDevice.current.identifierForVendor!.uuidString

OC code example:

UIDevice *currentDevice = [UIDevice currentDevice];
NSString *deviceId = [[currentDevice identifierForVendor] UUIDString];

# Android

Android devices can be obtained through ANDROID_ID (opens new window):

Java code example:

import android.provider.Settings.Secure;
private String android_id = Secure.getString(getContext().getContentResolver(),
                                                        Secure.ANDROID_ID);

Kotlin code example:

val deviceID = Settings.Secure.getString(contentResolver,
Settings.Secure.ANDROID_ID)
POST
https://core.authing.cn/oauth/sso/mobile/createSession

Create session

This interface is used to create a session in a mobile application client, and the user needs to be logged in, add the authorization request header to the request header to carry the user token.

Headers
authorization
REQUIRED
string

Login user's token

content-type
REQUIRED
string

application/json

Body Paramter
appId
REQUIRED
string

Mobile application ID, any string, please make sure it is unique within your application.

deviceId
REQUIRED
string

Device ID

userPoolId
REQUIRED
string

User pool ID

200: OK
{
    code: 200,
    message: "Creating session successfully!",
    data: {
        sessionId: "xxxxxx", // session ID
    }
}

Swift code example:

func createSession(userPoolId: String, token: String){
    // Mobile SSO: createSession
    struct MobileSSO: Encodable {
        let userPoolId: String
        let deviceId: String
        let appId: String
    }
    let body = MobileSSO(
        userPoolId: UserPoolId,
        deviceId: UIDevice.current.identifierForVendor!.uuidString,
        appId: "app1"
    )
    let headers: HTTPHeaders = [
        "Authorization": token,
        "Accept": "application/json"
    ]
    let api = "https://core.authing.cn/oauth/sso/mobile/createSession"
    AF.request(api, method: .post, parameters: body, encoder: JSONParameterEncoder.default, headers: headers).response {response in
         debugPrint(response)
    }
}

GET
https://core.authing.cn/oauth/sso/mobile/trackSession

Query session

This interface is used to query the session in the mobile application client without the user being in the login state.

Headers
content-type
REQUIRED
string

application/json

Body Paramter
deviceId
REQUIRED
string

Device ID

userPoolId
REQUIRED
string

User pool ID

200: OK

There are two situations: return user information directly and return ticket

// Return user information directly
{
    code: 200,
    message:'Get session user information successfully',
    data: {
      "_id":"5e05bbf2d51b3761d5c71070",
      "email":"983132@qq.com",
      "emailVerified":false,
      "oauth":"",
      "registerMethod":"default:username-password",
      "username":"983132@qq.com",
      "nickname":"",
      "company":"",
      "photo":"https://usercontents.authing.co/authing-avatar.png",
      "token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7ImVtYWlsIjoiOTgzMTMyQHFxLmNvbSIsImlxxxxxxxxx",
      "phone":"",
      "tokenExpiredAt":"2020-01-11T08:08:18.000Z",
      "loginsCount":1,
      "lastIP":"::1",
      "signedUp":"2019-12-27T08:08:18.115Z",
      "blocked":false,
      "isDeleted":false
    }
}

// return ticket
{
    code: 200,
    message:'Get session user information successfully',
    data: {
      ticket: "xxxxdjdkxxxxx",
      nickname: "xxxx",
      photo: "https://usercontents.authing.co/authing-avatar.png"
    }
}

The data returned by Authing trackSession supports two forms (you can modify it in the Authing console settings directory):

  1. Return complete user information directly, including token
  2. Return the nickname avatar (for display purposes) and the ticket in exchange for user information (default method)

The second method is recommended, because the first method has security risks, and there is the possibility that a third party illegally simulates the device ID to query the session in batches. Using a ticket requires you to use the user pool key in exchange for user information on the backend (see below for details), ensuring that user information will not be illegally obtained.

If you use the second method, you can display user nicknames and avatars on the front end, as shown in the following figure:

POST
https://core.authing.cn/oauth/sso/mobile/exchangeUserInfoWithTicket

Use ticket in exchange for user information

Use ticket in exchange for user information. This interface requires a user pool key, please call it on the backend!

Headers
content-type
REQUIRED
string

application/json

Body Paramter
ticket
REQUIRED
string

Ticket obtained by trackSession

secret
REQUIRED
string

User pool key

userPoolId
REQUIRED
string

User pool ID

200: OK
{
   "code":200,
   "message": "Successful in exchange for user information",
   "data":{
      "_id":"5e05bbf2d51b3761d5c71070",
      "email":"983132@qq.com",
      "emailVerified":false,
      "oauth":"",
      "registerMethod":"default:username-password",
      "username":"983132@qq.com",
      "nickname":"",
      "company":"",
      "photo":"https://usercontents.authing.co/authing-avatar.png",
      "token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7ImVtYWlsIjoiOTgzMTMyQHFxLmNvbSIsImlxxxxxxxxx",
      "phone":"",
      "tokenExpiredAt":"2020-01-11T08:08:18.000Z",
      "loginsCount":1,
      "lastIP":"::1",
      "signedUp":"2019-12-27T08:08:18.115Z",
      "blocked":false,
      "isDeleted":false
   }
POST
https://core.authing.cn/oauth/sso/mobile/destorySession

Destroy session

This interface is used to destroy a session in a mobile application client, and the user needs to be logged in, add the authorization request header to carry the user token in the request header. Because there are multiple applications, by default only the session of the specified App will be destroyed (trackSession will be queried as long as one App has a session). If you want to clear all App sessions, you can set destroyAll to true.

Headers
authorization
REQUIRED
string

Login user's token

content-type
REQUIRED
string

application/json

Body Paramter
destoryAll
OPTIONAL
boolean

Whether to destroy all App sessions on the same device, the default is false

appId
REQUIRED
string

Mobile application ID, any string, please make sure it is unique within your application.

deviceId
REQUIRED
string

Device ID

userPoolId
REQUIRED
string

User pool ID

200: OK
{
    code: 200,
    message: "Destroy the session successfully!"
}

You should call this interface every time the user logs out and deletes the app.