The Authentication Log answers "who signed in, how, and from where?" for your organization without asking DevStride support to look it up. It is the place to start when a member says they can't get in, or when you want to confirm everyone uses your company's single sign-on.
Configure Settings → Admin → Authentication Log. The page needs the View Authentication Log permission. The Owner and Admin roles hold it, as does any role that could manage permissions when the log was introduced; Members never do. It is part of no role template, so grant it to a custom role on its own if someone such as an IT lead should read the log without managing people. See Roles & Permissions.
Everything on the page is kept for 90 days, and a person's entries are removed when they or the organization are deleted.
One entry is added the first time a person's sign-in session opens this organization. Someone who belongs to several organizations appears only in the ones they actually opened, and switching back and forth within one session adds nothing new.
| Column | Shows |
|---|---|
| Member | Who signed in |
| Signed in with | Password, Google or Microsoft, or Company single sign-on, with the provider's name when it is one of this organization's own (for example Acme Okta (Company single sign-on)) |
| First opened this organization | When the session first opened the organization |
| Signed in | When the person signed in |
| Network address | The address the sign-in came from |
Filter by member, by sign-in method, or by a From / To date range, and use Load more for older entries.
Sign-ins made with an API key or a connector's token are not recorded; the log covers people signing in.
For each current member: whether they still have a DevStride password, and exactly which Google, Microsoft and company single sign-on names are linked to their account. Names are shown exactly as the sign-in service stores them, which is what matters when a single sign-on name must match an account letter for letter.
Only providers that belong to your organization are named. A member's link to another organization's single sign-on is not shown.
When your company single sign-on refuses someone, their browser reports the reason to DevStride, and it is listed here with the time, the provider and the reason in plain words. The sign-in service does not say who was refused, so no names are shown. Use the time to match a refusal with the member who told you they couldn't get in. Reports come from browsers rather than from the sign-in service itself, and only for your organization's active single sign-on providers.
The log is not available to the AI Assistant or to AI tools connected through the DevStride MCP server. Over the API, a key can read it only if the person who owns the key holds View Authentication Log.
Training Sandbox Guide
A follow-along training session for a training sandbox: sign in as each practice account and work through planning, sprint delivery, the Service Desk, the customer portal and reporting in the Acme demo organization.
Understanding Permissions
How roles and sharing combine to decide what each person can see and do, why the Owner role is special, and three common setups you can copy.