The purpose of this document is to briefly explain the main concepts around session management used by this kind of application.
There are two types of "sessions" used for solving security mechanisms, depending on the type of application (referring to applications using GAM):
In Web applications, "web sessions" are used to store all the information needed to solve authentication problems (remain authenticated as long as the session does not expire).
Read about how to change the Web Session timeout at WebSessionTimeOut property in GAMSecurityPolicy EO.
In Native Mobile applications, there is a "local session" stored in the device (the client tier) with the access_token that enables communication with REST Web Services and requires authentication (see Secure Native Mobile applications architecture for more information).
Unlike web applications, where authentication is checked via web sessions only, native mobile applications cache a "local session" that stores the access_token which makes communication possible between the application installed on the device and the REST web services residing on the server. In this case, the authorization mechanism is based on OAuth.
To connect to a secure Native Mobile application, the end user will need an authorized username/password. These credentials will be used together with the Client Id and Client Secret information downloaded to the device when the application is installed, to establish the first connection to the server application.
When the user tries to connect to the application, a login prompt is displayed. The first time the user tries to connect, a POST is made to the server using their username, password, client_id, and client_secret, and the HTTP Response returns an access_token which will be used during the connection.
This access_token is stored in the device and can either remain unchanged while the user is connected or be reset regularly depending on the value of the OauthTokenExpire property in GAMSecurityPolicy EO.
The access_token is stored in the device cache, and while it's valid (the user does not log out) the end user will not be prompted to log in again.
The local session is deleted when the user logs out from the application.
1. The time expiration criteria for OAuth Token Expire is different from the web session expiration timeout. They are related to elapsed time and idle time, respectively.
2. Remember that all the Security Policies and Repository configuration can be done through the GAM API.
Sample
The following code creates a Security Policy and sets its SessionTimeout and OAuth Token Expire.
&GAMSecurityPolicy.Id = &Id //&GAMSecurityPolicy is GAMSecurityPolicy Type
&GAMSecurityPolicy.Name = "TESTSecurityPolicy"
&GAMSecurityPolicy.WebSessionTimeOut = 10
&GAMSecurityPolicy.OauthTokenExpire = 15
&GAMSecurityPolicy.Save()
If &GAMSecurityPolicy.Success()
commit
Else
&GAMErrors = &GAMSecurityPolicy.GetErrors() //&GAMErrors is GAMError collection type
For &GAMError in &GAMErrors
Msg(Format("%1 (GAM%2)", &GAMError.Message, &GAMError.Code))
EndFor
Endif
Secure Native Mobile applications architecture
Anonymous Sessions in GAM - Web Applications