Applications
An application in BlokSec represents a service that your users sign in to using passwordless authentication. Each application uses one federation protocol (OIDC, SAML, or WS-Federation) and has its own configuration, branding, and user assignments.
Creating an application
Section titled “Creating an application”- In the admin console, navigate to Applications
- Click Add Application
- Fill in the basic information:
- Application Name (required) — a display name your users will recognize
- Application Type — choose OIDC, SAML, WS-Federation, or Windows Passwordless
- Logo (optional) — a URL to your application’s logo
- Login Page URL (optional) — where users are directed to sign in
- Session Length (optional) — how long a session lasts before re-authentication is required
- Complete the protocol-specific configuration (see below)
- Click Create
OIDC applications
Section titled “OIDC applications”OpenID Connect is the recommended protocol for modern web applications. BlokSec acts as an OIDC Provider, issuing ID tokens and access tokens to your application.
Required settings
Section titled “Required settings”| Setting | Description |
|---|---|
| Redirect URIs | URLs where BlokSec sends the user after authentication. Must match exactly what your application sends in the authorization request. Add at least one. |
| Post-Logout Redirect URIs | URLs where BlokSec sends the user after logout. Optional but recommended. |
| Token Endpoint Auth Method | How your application authenticates when exchanging the authorization code for tokens. Default: client_secret_basic. |
Grant types
Section titled “Grant types”BlokSec supports these OIDC grant types:
- Authorization Code (default) — standard browser-based login flow
- Client Credentials — server-to-server authentication without a user
- Refresh Token — allows your app to get new access tokens without re-authenticating the user
Client credentials
Section titled “Client credentials”After creating an OIDC application, you’ll receive:
- Client ID — derived from the application’s DID. Use this in your authorization requests.
- Client Secret — generated on demand from the application detail page. Keep this secret — it’s used to authenticate your application at the token endpoint.
Public clients (SPAs)
Section titled “Public clients (SPAs)”For single-page applications that can’t securely store a client secret, set the token endpoint auth method to none. BlokSec will require PKCE (S256 method) for these clients.
SAML applications
Section titled “SAML applications”SAML 2.0 is commonly used in enterprise environments. BlokSec acts as a SAML Identity Provider (IdP), generating signed assertions for your Service Provider (SP).
Required settings
Section titled “Required settings”| Setting | Description |
|---|---|
| Entity ID | A unique identifier for your SAML application (usually a URL). Must match what your SP sends in AuthnRequests. |
| Assertion Consumer Service (ACS) URLs | Endpoints where BlokSec posts the SAML response. Add at least one. |
| NameID Source | What value to use as the NameID in assertions: Account Name (the user’s account identifier) or User Email. |
Optional settings
Section titled “Optional settings”| Setting | Description |
|---|---|
| NameID Format | The format of the NameID claim. Common values: emailAddress, persistent, transient, unspecified. |
| Single Logout (SLO) URL | URL for SAML single logout. Optional. |
| Require Signed Requests | If enabled, BlokSec will reject unsigned AuthnRequests from your SP. |
| Custom Attributes | Additional attributes to include in the SAML assertion. |
BlokSec IdP metadata
Section titled “BlokSec IdP metadata”After creating a SAML application, you’ll need to configure your SP with BlokSec’s IdP metadata. You can:
- Download the metadata XML from the application detail page
- Copy the metadata URL to configure automatic metadata refresh
The metadata includes BlokSec’s entity ID, SSO endpoint URL, SLO endpoint URL, and signing certificate.
WS-Federation applications
Section titled “WS-Federation applications”WS-Federation is primarily used for Microsoft Azure AD and Office 365 integration. WS-Federation applications are automatically configured — you only need to provide the basic application information.
After creation, BlokSec generates the required certificates and metadata. See the Microsoft 365 integration guide for detailed setup instructions.
Custom claims
Section titled “Custom claims”All application types support custom claims. Navigate to the Custom Claims tab when editing an application to define additional attributes to include in tokens (OIDC) or assertions (SAML).
Each custom claim has:
- Name — the claim/attribute name as it appears in the token or assertion
- Value — mapped from user or account attributes
Account schema
Section titled “Account schema”The Account Schema tab lets you define custom attributes for accounts associated with this application. These attributes are stored per-account and can be used in custom claims.
Each attribute has:
- Name and Display Name
- Type — string, enum (single choice), or multi-select
- Required flag
- Default value
Branding
Section titled “Branding”By default, applications inherit your organization’s branding (logo, colors). Toggle Override Client Branding to customize the login experience for a specific application with its own logo and background.
Testing the integration
Section titled “Testing the integration”After configuring an application:
- Assign at least one user to the application
- Open your application’s login page
- Initiate a sign-in — you should be redirected to the BlokSec login screen
- Authenticate using the BlokSec app on your phone
- Verify you’re redirected back to your application and signed in
If authentication fails, check the Monitoring page for request details and error information.