Quick start guide
Learn how to identify your users in just a few steps. You can integrate with Signicat in three ways; by using OpenID Connect (OIDC) or SAML 2.0 or via Signicat's Authentication REST API.
Initial preparations
The guides below assume you've completed the initial setup steps:
- Sign up to the Signicat Dashboard.
- In the Signicat Dashboard, set up an organisation and an account. Additionally, to use the eID Hub product you need to set up a domain.
We advise you to create a sandbox account to test our solutions before implementing them in a production account.
Try it out
Add an ID method
- In the Signicat Dashboard, go to eID Hub > ID Methods.
- To enable the ID method, click Add new in the top right.
- Choose the ID method from the list, for example Norwegian BankID. Then, click Save.
- Now you can see the ID method listed and enabled with status "Active" in the ID methods list.
In a production account, you may need to obtain additional certificates or comply with data protection regulations to retrieve specific data attributes. You can learn more about the requirements for your desired method on the ID methods page.
Choose a protocol
Before you can start integrating, you'll need to know which authentication protocol to use. Signicat's identity hub supports three main protocols. Depending on your case, you may want to pick one of:
Picking a protocol
Choice of protocol depends on what you prefer, what your application supports and what you want to achieve.
OIDC and SAML are official identity protocols, while the Authentication REST API is a solution developed and maintained by Signicat.
The Signicat Authentication REST API gives you a lot of flexibility and supports headless and redirect integration flow(s) (grant type).
If you want to use an official identity protocol, we recommend using OIDC, since SAML 2.0 is much more complex to implement on your side and usually requires a federation agent already in place. OIDC is industry standard and you do not need to manage user sessions on your own (like with the Authentication REST API).
To understand the basics of how to use either of these protocols continue to the Set up a protocol section below.
Set up a protocol
- OpenID Connect
- SAML 2.0
- Authentication REST API
This guide explains how to set up authentication with OIDC. This guide is generic and agnostic of any programming langauge. If you would like a more detailed guide, refer to the Code examples for OIDC, which has language-specific guides.
To make your application work with OIDC, you first need to obtain:
- An OIDC client ID
- An OIDC client secret (optional, but recommended)
- Either an issuer URL or a discovery URL (depending on your implementation)
The next steps of this guide show how to obtain each one.
1. Obtain the client ID and client secret
- In the Dashboard, go to eID Hub > OIDC clients, and click the name of the client you want to use (or create a new one). If you're not sure which scopes to use for your client, select at least
openid
andprofile
. - Copy the client ID that is shown on the screen.
- Depending on whether you already created the client, select Add secret or navigate to the Secrets tab of your client and select Add secret.
- Enter a name for the secret you want to create. Then, click Generate secret.
- Copy the secret that is displayed on the screen and save it so you can use it in the code of your application. Then, click Ok.
2. Figure out your discovery URL or issuer URL
Both items are based on the domain you're using. Which one you will need depends on how you've implemented your product.
- The discovery URL can be accessed at the following URL:
<YOUR SIGNICAT DOMAIN>/auth/open/.well-known/openid-configuration
. For example, if your domain ishttps://verybigcorp.signicat.com
, your discovery URL ishttps://verybigcorp.signicat.com/auth/open/.well-known/openid-configuration
. - The issuer URL has this structure:
<YOUR SIGNICAT DOMAIN>/auth/open/
. For example, following the example in the previous bullet point, your issuer URL ishttps://verybigcorp.signicat.com/auth/open/
3. Prepare your integration
Prepare the code for your integration, using the information obtained in the previous steps.
This guide explains how you can exchange metadata files with Signicat in order to set up a SAML connection.
To learn more about integrating with Signicat using SAML, follow the steps in the Set up SAML documentation.
How to exchange SAML metadata
You have to provide Signicat with a metadata file to set up a secure connection over SAML. A metadata file contains information about the service provider (SP) and the identity provider (IdP) involved in an authentication process. For example, the metadata contains the details of where to send the response that is generated after an authentication session.
To integrate your SAML application with Signicat, you need to configure the metadata in the Dashboard. There are two options:
- URL (dynamic). You host the metadata and share the metadata URL with Signicat.
- Form (static). You upload the metadata file in the Dashboard or fill in the form in the Dashboard to have us generate the metadata file for you.
- With URL
- With Form
To add your URL metadata configuration:
- In the Dashboard, go to eID Hub > SAML 2.0.
- Select Add new. Then, select the URL configuration method to configure the metadata.
- Fill in the configuration. You can find information about the required information in the table below.
- Select Add to save the configuration.
- Click Get Signicat metadata to download the Signicat metadata file in XML format.
List of URL configuration fields
Required fields are marked with an asterisk (*).
Field name | Description |
---|---|
Name* | Name of the connection |
Application URL | URL of your application |
Metadata URL* | Link to your SAML metadata file |
Select a LoA contract* | Select the mapping between levels of assurance that must apply to this configuration. LoA contracts can be configured under Level of assurance contracts. |
Select attribute filter | Select which attributes you want to filter out, if any. They must be configured in Attribute filters. |
Response attribute mapping | You can choose to customise the name of the attributes received in the response body. |
Learn more about advanced configuration in the URL configuration section of the SAML 2.0 documentation.
To add your Form metadata configuration:
- In the Dashboard, go to eID Hub > SAML 2.0.
- Select Add new. Then, select the Form configuration method to configure the metadata.
- If you've already created your metadata file, upload it here. Otherwise, configure it using the form fields below.
- Select Add to save the configuration.
- Click Get Signicat metadata to download the Signicat metadata file in XML format.
List of form configuration fields
Required fields are marked with an asterisk.
Field name | Description |
---|---|
Name* | Name of the connection |
Application URL | URL of your application |
Entity ID* | Your unique identifier |
Select a LoA contract* | Select the mapping between levels of assurance that must apply to this configuration. See Level of Assurance contracts for more information. |
Want assertions signed | If ticked, assertions will be signed. |
Use a transient format for the NameID | Tick this box if you only want a transient NameID. |
Include the SAML Assertion of the IdentityProvider if available | If the ID methods that you use are SAML-based, you may opt to receive the original SAML assertion of the ID method. |
Encrypt assertion | If you want to receive an EncryptedAssertion instead of an Assertion for added security, select this option. Note that some ID methods require you to receive an EncryptedAssertion . |
Assertion consuming services* | At least one assertion consuming service must be configured. Provide a location URL and a binding type (REDIRECT / POST / ARTIFACT). |
Single logout services | Enter the location URL and binding type (REDIRECT / POST / ARTIFACT) of any applicable single logout services. |
Artifact resolution services | Enter the location URL, binding type and index of any applicable artifact resolution services. |
Attribute consuming services | Enter name, index, description (optional) and at least one attribute |
Certificate* | Upload all relevant certificates for the connection (at least one). Information about the certificates, such as issuer and expiration date, is displayed when they are uploaded. |
Client organisation | Enter organisation name, display name, and URL. |
Hosting party organisation | Provide organisation name, display name, and URL. |
Contact people | Provide details about the contact people in your organisation. In Type of contact person, specify whether they are part of support, a technical department, name, phone number, and more. |
Response attribute mappings | You can customise the name of the attributes received in the response body. You can provide none or many name-to-name mappings. |
Select attribute filter | Select which attributes you want to filter out, if any. They must be configured in Attribute filters. |
Select default broker service | Select which default broker service to use. This can be configured in the Dashboard in Advanced > Broker services. |
Learn more about advanced configuration in the Form configuration section of the SAML 2.0 documentation.
Metadata file example
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_9ef5602b6f9ed8b75334f563f91322d2"
entityID="yourEntityId">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
... XML Signature ...
</ds:Signature>
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>someKeyName</ds:KeyName>
<ds:X509Data>
<ds:X509Certificate>
x509 encoded certificate
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://yourdomain/saml/acs" index="0"
isDefault="true"/>
</md:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">Your organizationName</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">Your organizationDisplayName</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en">https://yourDomain</md:OrganizationURL>
</md:Organization>
</md:EntityDescriptor>
SAML examples
When the end-user wants to authenticate to your services over a SAML connection, the identity provider and the service provider communicate sending a request (AuthnRequest
) and a response (AuthnResponse
).
Below, you can find examples of request and response. To view more examples, go to the SAML examples documentation.
AuthnRequest examples
The SAML AuthnRequest
can be simple. You can always add more information in the request, but the request can be as minimal as:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AttributeConsumingServiceIndex="1"
Destination="https://yourdomain/broker/sp/saml/login" ForceAuthn="true"
ID="_b6a016332e19a825bb42917c9870c93a" IssueInstant="2021-03-09T10:26:17.210Z"
Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
yourEntityID
</saml2:Issuer>
<ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
... XML Signature ...
</ds:Signature>
</saml2p:AuthnRequest>
AuthnResponse example
Example of a SAML response AuthnResponse
after logging in with eHerkenning:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://yourDomain/saml/acs" ID="_8ecbe9dcd8c6e4765d5b6bd9cf5f2010" InResponseTo="_6dee7048f7b558987b5d9900e1b20832" IssueInstant="2023-12-11T12:35:48.235Z" Version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://yourBrokerDomain/auth/saml</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
... XML Signature
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_03c096c04b157811ec2af48c91e4d618" IssueInstant="2023-12-11T12:35:48.263Z" Version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer>https://yourBrokerDomain/auth/saml</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
... XML Signature
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="urn:etoegang:HM:00000003244440010000:entities:9713">k5QDBPNavooSgsxQNCITxSnQc5oo37cqev726-Iz1-Y=</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_6dee7048f7b558987b5d9900e1b20832" NotOnOrAfter="2023-12-11T12:37:48.263Z" Recipient="https://yourDomain/saml/acs"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2023-12-11T12:35:43.263Z" NotOnOrAfter="2023-12-11T12:37:48.263Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://yourDomain/saml</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="name">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Gerarda Josephina Kierkegaard</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="firstName">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Gerarda Josephina</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="lastName">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Kierkegaard</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="email">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">email@example.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="pseudo">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">03659FB1FAE5D26DB2D28866C1A4FE7F4E1CD5E62DD2552EE3D3B11D4C27163D@9162F54B3B07284AC4E147A849DEAEE4</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="kvkNr">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">24444001</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="rsin">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">819935177</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="serviceID">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">urn:etoegang:DV:00000003244440010000:services:9121</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="serviceUUID">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">cf1c1457-cc97-4b47-a324-25d1a97db3cb</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="intermediateKvkNr">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">24444002</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="companyName">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Signicat</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="intermediateCompanyName">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Intermediary</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2023-12-11T12:35:48.264Z" SessionIndex="14779d0d-08bb-4929-95a2-499363b122f7">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
<saml2:AuthenticatingAuthority>urn:etoegang:HM:00000003244440010000:entities:9713</saml2:AuthenticatingAuthority>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>
Learn more
Integrate with an ID method to identify your end-users or explore the SAML 2.0 documentation to discover advanced topics.
The Signicat Authentication REST API enables you to easily and securely authenticate your end-users. With the Authentication REST API, you can offer a variety of authentication flows from your backend systems which can often result in a less complex integration compared to OIDC and SAML.
The main advantages of using this API compared to OIDC and SAML are:
- You do not need to implement complex protocols - it's just a very simple REST API.
- You can support complex flows such as headless flow.
The biggest disadvantages are:
- You always need a backend to do the API calls securely.
- You may have to write more custom code compared to using a pre-made library or SDK for OIDC or SAML.
Available flows
The Authentication REST API supports redirect and headless flow.
Redirect flow
This is most likely the flow you want to use. Using the redirect flow, you are able to pass a URL to your end-users which they will open in a browser. The flow is called a redirect flow because during the authentication session, your end-users are redirected several times. At the end of this redirect chain they will arrive at what you have defined as the "success callbackUrl" for that specific session. This should be an endpoint at your backend. Your backend will then get the authentication session from our endpoint, which includes the information about the authenticated person (subject).
Sequence diagram example
Headless flow
The headless flow allows you to provide your own user interface within your app or website. This is currently only available for Swedish BankID. For more details, see Headless flow.
API reference
In our Authentication REST API reference, you can find information about the available endpoints and properties, as well as sample requests and responses.
Test the flow
Run your application locally and test the authentication flow.
You will need a test user to complete the authentication. For example, you can use the following credentials for Norwegian BankID:
National identity number | One-time password | Password |
---|---|---|
01100844350 | otp | qwer1234 |
For information on creating test users for a specific ID method, you can find your desired method on the ID methods page, which includes test information.