How User Authentication Is Done with Okta Advanced Server Access

This article outlines the steps involved in user authentication through Okta Advanced Server Access when the server has been enrolled with an agent. 

• Okta Advanced Server Access

User Authentication Flow:

1. The user logs in to the ASA dashboard through Okta SAML authentication. As per the assigned role, ASA will generate a signed JWT for the user session. 

2. The user then enrolls a client which, when approved, will get a CLIENT JWT from ASA. This is a token that expires in 90 days and allows them to request an AUTHENTICATED_CLIENT token.
3. The user runs sft login through which the client requests the AUTHENTICATED_CLIENT token. This token will be used to request credentials and expire in ~10 hours (default and controlled by client session).
4. The user runs sft ssh/rdp SERVER, which uses that AUTHENTICATED_CLIENT token to request credentials for the server.
5. At the time of project creation, ASA generates a CA for that project. Any servers in that project sync down the public key for that CA, along with any users that need to be created periodically in the background.
6. When the user requests the credentials, ASA signs a time-limited (valid for ~3 mins in the future and ~2 mins in the past) certificate for them using the project CA with a key algorithm they choose for the project (the default today is ssh-ed25519). After this, the flow proceeds as per the protocol: 
   • For SSH : sft configures ssh to present that certificate to the target server sshd. The server will recognize the CA used to sign it and will accept the certificate. The certificate contains the username as the principal, which is how it knows which user to log them in as.
   • For RDP: sft rdp presents the certificate to agent broker process running on port 4421 on the target server which then communicates with RDP service for authentication. More information can be found in Connection and Authentication section.