The SASjs CLI has always required a registered OAuth client and secret to authenticate against SAS Viya. If you are a developer who just wants to run a SAS program from the command line, getting an administrator to register an OAuth client for you is friction you do not need. The new sasjs auth login command removes that barrier - you log in with your regular SAS username and password, and the CLI handles the rest.
sasjs auth login -t myviyatargetThat is it. You are prompted for your SAS username and password (the password input is masked), the CLI exchanges them for an access/refresh token pair, verifies the token, and persists it. From that point on, the stored token can be used by any command that accepts an access token - sasjs run, sasjs deploy, sasjs job execute, sasjs flow, sasjs fs, sasjs request, sasjs context, sasjs folder, sasjs test. No client or secret is needed for the initial login or for silent token refreshes (the built-in sas.cli public client handles those).
Before this feature, authenticating to Viya from the SASjs CLI meant:
\nsasjs auth (or sasjs add cred), which uses the authorisation code flow - you visit a URL in your browser, sign in, grant access, and paste back an authorisation codeThat is fine for production CI pipelines, but painful for a developer who just wants to test something quickly on a demo Viya instance. The new sasjs auth login command uses the OAuth2 resource owner password grant against the built-in, secret-less sas.cli public client - the same client the official SAS Viya CLI uses. No client registration, no secret, no browser redirect.
Under the hood, sasjs auth login does the following:
/SASLogon/oauth/token with grant_type=password, your username, and your password, authenticated with a Basic auth header for the sas.cli client (which has no secret).GET /identities/users/@currentUser with the access token to confirm it is valid and to identify the logged-in user.sasjs auth flow: .env.[target name] for local targets, ~/.sasjsrc for global targets.sas.cli client). No client/secret is needed for the refresh either.Viya refresh tokens are single-use and rotate on every refresh. The CLI persists the rotated pair automatically after every refresh - so the next CLI invocation always reads the latest valid pair, and you never end up with a stale refresh token.
\nFirst, make sure you have a target configured for your Viya server. If you do not have one yet, create one with the interactive wizard:
\nsasjs addThe command prompts you for the target name, server type (pick SAS Viya), server URL, and app location. You can skip the authentication step at the end - sasjs auth login will handle that separately.
Then log in:
\nsasjs auth login -t myviyatarget\n# Please enter your SAS username: viyademo01\n# Please enter your SAS password: ********\n# Logged in as viyademo01 (Viya Demo User) on https://your-viya-server.com.Now run any command:
\nsasjs run myprogram.sas -t myviyatargetWhen the access token expires (12 hours by default, though some estates configure shorter TTLs for the sas.cli client), the CLI will silently refresh it. If the refresh token itself expires, just run sasjs auth login -t myviyatarget again.
--password command-line flag exists. Passing a password as a command-line argument would leak it via shell history and process listings (ps). The CLI deliberately does not offer this option.--insecure flag for self-signed certs. If your Viya server uses self-signed certificates, pass --insecure (or -i) to bypass TLS validation: sasjs auth login -t myviyatarget --insecure. This is not recommended for production.sasjs auth login supports both interactive and non-interactive credential input. For CI pipelines and automated environments, there are three non-interactive patterns:
Environment variables:
\nSAS_USERNAME=viyademo01 SAS_PASSWORD=secret sasjs auth login -t myviyatargetWhen both SAS_USERNAME and SAS_PASSWORD are set, the CLI skips the prompts entirely.
Password via stdin (avoids shell history leakage):
\necho \"$SAS_PASSWORD\" | sasjs auth login --password-stdin -t myviyatargetWhen --password-stdin is set, the password is read from stdin and the username must come from the SAS_USERNAME environment variable (stdin is reserved for the password, so interactive prompting is not possible).
Credential precedence:
\nSAS_USERNAME env var > interactive prompt (TTY only)--password-stdin > SAS_PASSWORD env var > interactive prompt (TTY only)If no TTY is available and no env var or stdin flag supplies the credential, the command throws with a clear message pointing at the env vars or --password-stdin. This makes it safe to call from CI pipelines and non-interactive agents.
sas.cli client. This is the default on most Viya deployments, but administrators can disable it.sasjs auth login cannot work on SSO/SAML/MFA-only estates - those require the browser-based authorisation code flow.sasjs run may appear to hang. Subsequent runs are fast.sasjs run fails with a 403 when creating a compute session, your account may not be authorised for the configured compute context. Check the available contexts and update the contextName on your target accordingly.sasjs auth) remains the recommended approach.The bare sasjs auth command (without the login subcommand) still works exactly as before - it is an alias for sasjs add cred and uses the client/secret authorisation code flow. Nothing changes for existing setups. The login subcommand is purely additive.
The sasjs auth login command is available in the latest SASjs CLI release. If you have been putting off trying the SASjs CLI because you did not want to deal with OAuth client registration, this is your excuse to give it a go.