Access token

In computer systems, an access token contains the security credentials for a login session and identifies the user, the user's groups, the user's privileges, and, in some cases, a particular application.^[1] In some instances, one may be asked to enter an access token (e.g. 40 random characters) rather than the usual password (it therefore should be kept secret just like a password).

Overview

An access token is an object encapsulating the security identity of a process or thread.^[2] A token is used to make security decisions and to store tamper-proof information about some system entity. While a token is generally used to represent only security information, it is capable of holding additional free-form data that can be attached while the token is being created. Tokens can be duplicated without special privilege, for example to create a new token with lower levels of access rights to restrict the access of a launched application. An access token is used by Windows when a process or thread tries to interact with objects that have security descriptors (securable objects).^[2] In Windows, an access token is represented by the system object of type Token.

An access token is generated by the logon service when a user logs on to the system and the credentials provided by the user are authenticated against the authentication database. The authentication database contains credential information required to construct the initial token for the logon session, including its user id, primary group id, all other groups it is part of, and other information. The token is attached to the initial process created in the user session and inherited by subsequent processes created by the initial process.^[2] Whenever such a process opens a handle to any resource which has access control enabled, Windows reconciles the data in the target object's security descriptor with the contents of the current effective access token.^[3] The result of this access check evaluation is an indication of whether any access is allowed and, if so, what operations (read, write/modify, etc.) the calling application is allowed to perform.

Types of token

There are two types of tokens available:

Primary token

Primary tokens can only be associated to processes, and they represent a process's security subject. The creation of primary tokens and their association to processes are both privileged operations, requiring two different privileges in the name of privilege separation - the typical scenario sees the authentication service creating the token, and a logon service associating it to the user's operating system shell. Processes initially inherit a copy of the parent process's primary token.

Impersonation token

Impersonation is a security concept implemented in Windows NT that allows a server application to temporarily "be" the client in terms of access to secure objects. Impersonation has four possible levels: anonymous, giving the server the access of an anonymous/unidentified user, identification, letting the server inspect the client's identity but not use that identity to access objects, impersonation, letting the server act on behalf of the client, and delegation, same as impersonation but extended to remote systems to which the server connects (through the preservation of credentials). The client can choose the maximum impersonation level (if any) available to the server as a connection parameter. Delegation and impersonation are privileged operations (impersonation initially was not, but historical carelessness in the implementation of client APIs failing to restrict the default level to "identification", letting an unprivileged server impersonate an unwilling privileged client, called for it). Impersonation tokens can only be associated to threads, and they represent a client process's security subject. Impersonation tokens are usually created and associated to the current thread implicitly, by IPC mechanisms such as DCE RPC, DDE and named pipes.

Contents of a token

A token is composed of various fields, including:^[4]

• an identifier.
• the identifier of the associated logon session. The session is maintained by the authentication service, and is populated by the authentication packages with a collection of all the information (credentials) the user provided when logging in. Credentials are used to access remote systems without the need for the user to re-authenticate (single sign-on), provided that all the systems involved share an authentication authority (e.g. a Kerberos ticket server)
• the user identifier. This field is the most important and it's strictly read-only.
• the identifiers of groups the user (or, more precisely, the subject) is part of. Group identifiers cannot be deleted, but they can be disabled or made "deny-only". At most one of the groups is designated as the session id, a volatile group representing the logon session, allowing access to volatile objects associated to the session, such as the display.
• the restricting group identifiers (optional). This additional set of groups doesn't grant additional access, but further restricts it: access to an object is only allowed if it's allowed also to one of these groups. Restricting groups cannot be deleted nor disabled. Restricting groups are a recent addition, and they are used in the implementation of sandboxes.
• the privileges, i.e. special capabilities the user has. Most privileges are disabled by default, to prevent damage from non-security-conscious programs. Starting in Windows XP Service Pack 2 and Windows Server 2003 privileges can be permanently removed from a token by a call to AdjustTokenPrivileges() with the SE_PRIVILEGE_REMOVED attribute.
• the default owner, primary group and ACL for the token created by the subject associated to the token.

See also

• API key
• Claims-based identity
• Session ID
• JSON Web Token

References

1. "Access Token: Definition, Architecture, Usage & More". Okta. Retrieved 2022-06-08.
2. "Access Tokens". MSDN. Retrieved 2007-10-08.
3. "AccessCheck". MSDN. Retrieved 2014-02-13.
4. "How Access Tokens Work". MSDN. 8 October 2009. Retrieved 2014-02-13.