Trust
Authentication
Authentication answers one question: are you who you claim to be. It is not the same as authorisation, which asks what you may then do, and conflating the two is how products end up with strong logins and weak boundaries. This page covers the first. The permissions page covers the second.
- Quality and compliance
- Hospital operations
- Clinical engineering
What is authentication in Rydya?
Definition
Authentication and assurance level
Authentication in Rydya is email and password backed by an identity platform, optionally strengthened with a time-based one-time code, producing a session whose assurance level is carried in the token and re-checked by the server on every sensitive action rather than trusted once at login.
The phrase carrying the weight is re-checked by the server. A product that verifies multi-factor at the door and then trusts the session for eight hours has multi-factor on the login screen, not on the actions that matter. Step-up means the assurance level is a property the server tests when it counts.
The other thing worth stating plainly: token claims never drive authorisation here. What a token asserts about identity is input; what you may do is resolved server-side from your actual membership and grants. A token is evidence of who you are, never a statement of what you may do.
How a session is established and ended
Multi-factor where you require it, step-up on the actions that matter, and a revocation that does not wait for a token to expire.
TOTP multi-factor
Time-based one-time codes from an authenticator app. Not SMS, which is the weakest common second factor and the one most often described as though it were strong.
Step-up enforcement on sensitive routes
The assurance level is read from the token claim and gated per action, returning an explicit insufficient-assurance error rather than a generic denial. Sensitive actions require the stronger level even inside an existing session.
Server-side session revocation
Checked before tenant context resolves, so a revoked session stops working immediately rather than when its token happens to expire. This is the difference between revoking access and waiting for it to lapse.
Organisation suspension is enforced at authentication
A suspended organisation cannot transact regardless of what any individual token says, because the check sits in the same path that resolves the tenant.
Machine identities authenticate separately
Service accounts use scoped credentials with their own rate limits and revocation, entirely separate from human sessions. An integration is not a user with a long-lived password.
Why we distinguish what is ours from what is the platform's
Because a security page that claims its provider's properties as its own engineering is a page that will not survive a diligence question, and the question always comes.
Rydya runs on a hosted identity platform. That platform handles credential storage, the password reset flow, and the mechanics of issuing tokens. We build on top of it: the assurance gating, the revocation backstop, the tenant resolution, the rule that claims never drive authorisation. Those are ours and we will defend them.
Password strength rules and brute-force lockout are not ours. They are configuration in the identity platform's project settings, and our own deployment checklist marks them as an owner decision rather than a Rydya feature. We could describe them here in a way that read as though we had built them. Plenty of products do. It would be true in the sense that the behaviour exists and false in the sense that matters, which is who is accountable for it and where you go to change it.
The practical consequence for you: when you configure Rydya, someone on your side has to make those identity-platform decisions deliberately. They are not defaults we have chosen well on your behalf, and treating them as though they were is the gap this paragraph exists to close.
What is built, what is configuration, and what is absent
The distinction between these three columns is the whole point of the page.
| Capability | Status | Detail |
|---|---|---|
| TOTP multi-factor | Built | Authenticator app codes, with a challenge screen in the product. |
| Step-up on sensitive actions | Built | Assurance level gated per route, server side, explicit error. |
| Session revocation | Built | Server side, checked before tenant context resolves. |
| Organisation suspension | Built | Enforced in the authentication path, not by hiding the interface. |
| Service-account credentials | Built | Scoped, rate limited, revocable independently of any person. |
| Password policy | Your configuration | Set in the identity platform project. Not a Rydya feature. |
| Brute-force lockout | Your configuration | Same. We ship no lockout code of our own. |
| SAML or OIDC single sign-on | Not built | No enterprise SSO. If your identity team requires it, this is a real gap. |
| SCIM provisioning | Not built | No directory sync. Users are invited rather than provisioned. |
| Passkeys | Not built | No WebAuthn support today. |
Authentication capabilities by actual status
When the missing SSO actually matters, and when it does not
It matters to identity teams and to organisations above a certain size, and pretending otherwise wastes everybody's evaluation.
For a specialist clinic with eleven staff, no single sign-on is a non-issue and would be a solved problem in search of a purchase. For a hospital group with a directory, a joiners-and-leavers process and an identity team that owns access reviews, its absence means Rydya accounts are a separate population to manage and de-provision by hand. That is a real operational cost and it is theirs, not ours.
The honest framing is that this is a size threshold rather than a capability people either want or do not. Ask your identity team before you evaluate further, because the answer is likely already policy, and discovering it at contract stage after clinical stakeholders are invested is the expensive path.
We are not going to tell you it is on the roadmap in order to close the gap in a conversation. It is not built, and this page will say so until it is.
A token says who you are, never what you may do
This is the rule underneath everything above, and it is the one worth testing in any product. Authorisation in Rydya is resolved server-side from real membership and grants, never from a claim inside a token, because a claim is asserted by whoever minted the token and re-verifying it is the only thing that makes it a control. A product that reads permissions from a JWT has moved its access model into a string it hands to the client.
Questions
Do you support SAML single sign-on or SCIM provisioning?
No. Neither is built, and we will not describe it as roadmap to close a gap in a conversation. Authentication is email and password with TOTP multi-factor and step-up enforcement on sensitive actions, plus server-side session revocation. For a small clinic this is a non-issue; for a group with an identity team and a joiners-and-leavers process it is a real operational cost, and worth raising before you evaluate further.
What are your password rules and lockout policy?
They are yours rather than ours. Credential storage and password policy live in the hosted identity platform we build on, and our own deployment checklist marks them as an owner decision. We ship no lockout code. We could describe those settings here as though we had built them, and that would be true about the behaviour and false about who is accountable for it and where you go to change it.
Does multi-factor apply after login, or only at the door?
After. The assurance level is carried in the token and re-checked by the server on sensitive actions, returning an explicit insufficient-assurance error rather than a generic denial. A product that verifies multi-factor at login and then trusts the session for eight hours has multi-factor on the login screen, not on the actions that matter.
If we revoke someone's access, when does it take effect?
Immediately. Session revocation is checked server-side before tenant context resolves, so a revoked session stops working rather than continuing until its token happens to expire. Organisation suspension is enforced in the same path, so a suspended organisation cannot transact regardless of what any individual token asserts.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us