Sign-in
SAML and OIDC
For applications that only need to know who the user is, with group assignment, SCIM and claims mapping.
Platform / Applications
Application Types
WebFrolic connects six types of application: SAML; OpenID Connect in client and server flows; OAuth2 in client and server flows for access on a user’s behalf; and OAuth2 client credentials for machine-to-machine. Each application also carries its own assignment, assurance, session, SCIM, network and seat-license settings.
Available now in WebFrolic.
Why it matters
The wrong application type is the most common identity integration bug.
Using an ID token to call an API, or putting a client secret in a mobile app, are design mistakes the protocol cannot fix later. Picking the type by what the application needs — sign-in only, delegated access, or machine-to-machine — keeps each one on the right flow from the start.
Delegated access
OAuth2 client and server flows
Adds scopes, access tokens and a machine user, so the app can call resources on the user’s behalf.
Machine to machine
Client credentials
For services with no person present: scopes, a secret, access tokens and a network firewall.
Choosing a type
Six types, three jobs.
| Type | Best for | Purpose |
|---|---|---|
| SAML | Enterprise services and established SaaS applications. | Authentication |
| OIDC (client flow) | User sign-in for native mobile apps and single-page apps that cannot keep a secret. | Authentication |
| OIDC (server flow) | User sign-in for server-side applications that can store a client secret. | Authentication |
| OAuth2 (client flow) | Sign-in plus access to resources on the user’s behalf, for native mobile apps and SPAs. | Authorization |
| OAuth2 (server flow) | Sign-in plus access to resources on the user’s behalf, for server-side applications that store a secret. | Authorization |
| OAuth2 client credentials | Machine-to-machine communication with no person present. | Authorization |
Capabilities
What each application type supports.
| Type | Purpose | Redirect URLs | Group assignment | SCIM | Claims mapping | Scopes | Machine user | Client secret | Access tokens | Authorization flow | Network firewall |
|---|---|---|---|---|---|---|---|---|---|---|---|
| SAML | Authentication | — | ✓ | ✓ | ✓ | — | — | — | — | — | — |
| OIDC (client flow) | Authentication | ✓ | ✓ | ✓ | ✓ | — | — | — | — | ✓ | — |
| OIDC (server flow) | Authentication | ✓ | ✓ | ✓ | ✓ | — | — | ✓ | — | ✓ | ✓ |
| OAuth2 (client flow) | Authorization | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | — |
| OAuth2 (server flow) | Authorization | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| OAuth2 client credentials | Authorization | — | — | — | — | ✓ | ✓ | ✓ | ✓ | — | ✓ |
Settings on every application
More than a client ID.
| Setting | What it controls | Why it helps |
|---|---|---|
| Assignment | Assign to everyone, to individual users or to groups, and limit it to customers, employees or administrators. | Only the right people see and open the app. |
| Category | Internal, external or trusted external. | Treat your own apps and third-party apps differently. |
| Assurance level | The sign-in strength the application requires. | Sensitive apps ask for a stronger method. |
| Session duration | How long a session lasts for this application. | Short sessions where the risk is higher. |
| SCIM | Provision users, and optionally groups, to the application’s SCIM endpoint with its own auth header. | Accounts appear and disappear automatically. |
| Network firewall | Allow and deny rules on server-side and machine-to-machine applications. | Tokens are only usable from approved networks. |
| Seat licenses | Mark an app as paid, set a seat price and a user limit, and choose an assignment strategy. | See license cost and stop over-assignment. |
| Self-service | Whether employees can request the application. | Access requests without IT tickets. |
| Terms, privacy, logo and bookmark | Links, branding and a launch URL shown to users. | A clear, trusted app launcher. |
| Status | Active, disabled or pending configuration. | Switch an app off without deleting it. |
Seat licenses
Four ways to handle a user limit.
| Strategy | Behavior | Use it when |
|---|---|---|
| Unlimited | Any number of users can be assigned. | The app is not seat-licensed. |
| Fixed | A fixed limit; no users are added beyond it. | Seats are fixed by contract. |
| Replace stale | A fixed limit; the user who has not used the app for a while is removed to make room. | Seats are scarce and some users rarely sign in. |
| Flexible | A soft limit that warns but does not block. | You want visibility before enforcing a limit. |
In the console
Set it up in four steps.
Menu names match the WebFrolic console. The setup guide has the detail.
Pick the type
In Applications, create the application with the type that matches what it needs: sign-in, delegated access or machine-to-machine.
Configure the flow
Add redirect URLs, scopes and claims; server and client-credential types also get a client secret and network firewall rules.
Assign it
Assign it to all users, users or groups, limit it to a persona, and set its assurance level and session duration.
Provision and license
Turn on SCIM if the app supports it, and for paid apps set the seat limit and assignment strategy.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- List each application and whether it needs sign-in only, delegated access or machine-to-machine.
- Never use a client flow where the application could keep a secret on a server instead.
- Set a higher assurance level and shorter session on sensitive applications.
- Add network rules to server-side and machine-to-machine applications.
- For paid apps, set the seat limit and choose how to handle it.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.