Authentication Types
Dime.Scheduler supports two ways for users to sign in. Pick the one that fits how your customer manages identities. Both start from the same login page, so a user never has to know which one applies before they get there: the Sign in with Microsoft button at the top is the Entra ID route, and the Email and Password fields below it are the forms route.
Microsoft Entra ID​
Users sign in with their Microsoft credentials, and Azure passes a set of claims to Dime.Scheduler. Dime.Scheduler stores no credentials of its own and works only with the data the administrator has granted. The Entra ID App Registration needs nothing more than the user's email address to authenticate.
Users can grant consent individually, or the administrator can grant it on behalf of the whole organization. For production, use this consent link. To grant access to users on the sandboxSandboxThe separate Dime.Scheduler environment where upcoming features arrive before the production release. It has its own API host, sandbox.api.dimescheduler.com, so API clients target it explicitly., use this consent link.
This works much like signing in to other sites with a Facebook or Google account. There are real benefits for everyone. Users avoid keeping separate credentials for yet another application (and the password resets that come with it), and security improves because identity management rests with Microsoft, who can devote far more resources to it than any single vendor.
Forms​
Forms authentication is a standard, password-protected system that adheres to industry security standards. Administrators create users manually in the provided setup view, and the password is never set by the administrator: the new user receives a welcome email with a confirmation link and chooses their own.
That link opens the Confirm your email page. The Email field is filled in and cannot be changed; the user types a Password, repeats it under Confirm Password and clicks Confirm. A success screen with a Click here to sign in. button follows, and from then on the account works like any other forms account. The link does not last forever. When it no longer works, the user lands on the login page with an error and the forgot-password panel already open, and a reset link from there does the same job.
If a user forgets their password, there is no cause for concern. The Forgot password? link under the login button swaps the credentials form for a small panel on the same page that asks for the email address and sends a reset link.
Shared behavior​
A few things on the login page apply regardless of which route a user takes.
Organizations. A user account is tied to an organization, and the same email address can exist in more than one. When Dime.Scheduler finds several, it does not guess: after the credentials are accepted (or after Microsoft has confirmed the identity), the page switches to a Select organization view that lists each one as a card. Clicking a card completes the sign-in into that organization. Back to sign in returns to the form. The same picker appears when a forgot-password request matches several organizations, so the reset email goes to the right one.
reCAPTCHA. Submitting the credentials form, the forgot-password panel or the organization picker on a forms login runs an invisible reCAPTCHA check. There is nothing for the user to solve; the only visible sign is the reCAPTCHA badge in the corner of the page. A submission that fails the check is rejected as if the credentials were wrong. The Microsoft route does not go through reCAPTCHA because Microsoft has already verified the user.
Terms. Below the form, a line states that logging in means agreeing to the Terms of Service and Privacy Policy, with links to both. There is no checkbox: signing in is the agreement.