Documents the new sasjs auth login command - #30
Conversation
…ient/secret) - auth.md: new 'sasjs auth login' section covering syntax, the sas.cli password grant, token persistence, automatic refresh, and requirements/limitations (SSO-only estates, short TTLs, cold starts, compute context 403s); the Viya section now presents both flows - faq.md: the 'no password grant' statement updated; client/secret FAQ now points at sasjs auth login as a simpler alternative
![4gl-reviewer[bot]](https://avatars.githubusercontent.com/in/4587573?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hermes Agent Code Review
Verdict: Approve
Documentation-only PR describing the new sasjs auth login (password-grant against the public sas.cli client) flow. The content is accurate, well-structured, and the internal links resolve.
Warnings
- None blocking.
Suggestions
docs/auth.md: the intro sayssasjs auth loginis "Viya only" and the dedicated section restates "SAS Viya target" — good. One nit: the "All authenticated commands" list on the new line includessasjs context, which is not in the top-of-page list (line 11–18) of commands that use auth. Either addsasjs contextto the top list for consistency, or drop it from theauth loginparagraph so the two lists agree.- Pre-existing: line 64 still has
ACESS_TOKEN(missing C). Not introduced by this PR, but it's in a paragraph you edited — a cheap fix while you're here. - Per the PR notes, this should merge after the CLI feature PR lands, to avoid documenting unreleased behaviour. Worth confirming the CLI PR is merged/released before publishing.
Looks Good
- The ROPC / OAuth 2.1 deprecation admonition is clearly flagged and scoped to dev/demo use, with CI pointed to the client/secret flow — correct security framing.
- Requirements & limitations section is thorough: password-grant enablement, local/LDAP-only (no SSO/SAML/MFA), self-signed cert pointer to
httpsAgentOptions, cold-start compute delay, 403 →contextName: "SAS Studio compute context"hint. - Token-refresh note correctly calls out the short-TTL
sas.cliquirk and single-use rotating refresh tokens being persisted during long-running jobs. - The
#tls-configanchor target exists (line 153## TLS Config), and the#sasjs-auth-loginanchors resolve.
Reviewed by Hermes Agent (GitHub App)
| For the client / secret flow (`sasjs auth`), the CLI will only work with pairs that have the 'authorization_code' grant type. | ||
|
|
||
| Alternatively, `sasjs auth login` authenticates with a SAS username and password (no client/secret required) using the password grant against the built-in `sas.cli` public client. See [sasjs auth](/auth/#sasjs-auth-login). | ||
|
|
There was a problem hiding this comment.
Minor: the link text is See [sasjs auth](/auth/#sasjs-auth-login) but the anchor #sasjs-auth-login points at the sasjs auth login section, not sasjs auth. Suggest See [sasjs auth login](/auth/#sasjs-auth-login) so the text matches the destination.
- auth.md: document the --insecure/-i flag on sasjs auth login (self-signed estates), pointing to httpsAgentOptions as the fix - add.md: tip that users without a client/secret can skip the Viya credential prompt and use sasjs auth login instead
There was a problem hiding this comment.
Hermes Agent Code Review
Verdict: Approve — docs-only change accurately describes the new sasjs auth login flow implemented in sasjs/cli#1460. The --insecure flag description, the sas.cli password-grant details, the /identities/users/@currentUser verification step, and the token-rotation note all match the implementation. The cross-link from add.md and faq.md is helpful. One tiny pre-existing typo flagged inline; not a blocker.
✅ Looks Good
- The warning that the password grant is deprecated in OAuth 2.1 and intended for dev/demo estates is the right framing.
- Requirements/limitations section correctly notes SSO/SAML/MFA-only estates won't work.
- Token-expiry note correctly documents the single-use rotating refresh-token behaviour and the CLI's automatic persistence.
Reviewed by Hermes Agent (GitHub App)
|
|
||
| After you provide the client / secret, you are given a link which you must click to obtain the authorisation code. Be sure to select any scopes (such as openid) if presented. | ||
|
|
||
| Once you provide the authorisation code, the ACESS_TOKEN and REFRESH_TOKEN are saved and used for further connection requests. If the ACCESS_TOKEN expires (by default after 12 hours) the REFRESH_TOKEN will be used automatically to update, until it also expires (by default after 30 days). At this point, you will need to run `sasjs auth` once again. |
There was a problem hiding this comment.
💡 Suggestion (pre-existing): ACESS_TOKEN is missing a C — should be ACCESS_TOKEN. This line is unchanged by this PR but sits in the same section you're editing, so it's a cheap fix to fold in. Not a blocker.
1 participant
Summary
Documents the new
sasjs auth logincommand (see sasjs/cli PR from branchfeat/password-grant-auth), which lets users authenticate against SAS Viya with a regular SAS username/password — no registered OAuth client/secret required.Changes
docs/auth.mdsasjs auth: baresasjs auth(alias forsasjs add cred, unchanged) and the newsasjs auth loginsubcommand.sasjs auth login(recommended for developers) and the client/secret flow (recommended for CI pipelines). The outdated claim that "SASjs does not support password authentication grant type" is removed.sasjs auth login -t viya→Logged in as <id> (<name>)→sasjs run).env.[target]/~/.sasjsrc)sas.cliquirk and rotating single-use refresh tokens (persisted automatically, incl. during long-running jobs)sas.cli(default on Viya 3.5+/4); local/LDAP accounts only (no SSO/SAML/MFA); self-signed certificate guidance; cold-start compute session delays; 403 on unauthorised compute contexts (suggestSAS Studio compute context)docs/faq.mdsasjs auth login.sasjs auth loginfirst when the user just needs to run code as themselves.Notes