How User Authentication Works in Okta Advanced Server Access

User authentication through Okta Advanced Server Access (ASA) involves a specific sequence of steps when the server enrolls with an agent. The process includes generating JSON Web Tokens (JWT), requesting credentials, and presenting time-limited certificates to the target server.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Advanced Server Access (ASA)

How does user authentication work in Okta Advanced Server Access?

Review the following sequence to understand the user authentication flow in Okta Advanced Server Access.

1. The user logs in to the ASA dashboard through Okta Security Assertion Markup Language (SAML) authentication. Based on the assigned role, ASA generates a signed JSON Web Token (JWT) for the user session.
2. The user enrolls a client. Upon approval, the client receives a CLIENT JWT from ASA. This token expires in 90 days and allows the client to request an AUTHENTICATED_CLIENT token.
3. The user runs sft login, which prompts the client to request the AUTHENTICATED_CLIENT token. The client uses this token to request credentials. The token expires in approximately 10 hours (the default duration controlled by the client session).
4. The user runs sft ssh <SERVER> or sft rdp <SERVER>. This command uses the AUTHENTICATED_CLIENT token to request credentials for the server.
5. During project creation, ASA generates a Certificate Authority (CA) for the project. Servers in that project synchronize the public key for that CA, along with any users that require periodic background creation.
6. When the user requests the credentials, ASA signs a time-limited certificate (valid for approximately three minutes in the future and two minutes in the past) using the project CA and the selected key algorithm (the default is ssh-ed25519). The flow then proceeds based on the protocol:
   • For Secure Shell (SSH): The sft command configures SSH to present the certificate to the target server sshd. The server recognizes the CA used to sign the certificate and accepts it. The certificate contains the username as the principal, allowing the server to identify the user.
   • For Remote Desktop Protocol (RDP): The sft rdp command presents the certificate to the agent broker process running on port 4421 on the target server. The agent broker process then communicates with the RDP service for authentication. Review the Connection and Authentication documentation for more information.