# Automatically detect login
# Ready to work
# 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?
- The application downloaded from the App Store is judged based on the application information registered in the App Store.
- Apps not downloaded from App Store
- 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.
- 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)
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.
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)
}
}
Query session
This interface is used to query the session in the mobile application client without the user being in the login state.
The data returned by Authing trackSession supports two forms (you can modify it in the Authing console settings directory):
- Return complete user information directly, including token
- 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:
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!
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.
You should call this interface every time the user logs out and deletes the app.