Connect client applications
When you want to introduce licensing control for your software application using 10Duke APIs, the first step is to connect to 10Duke Enterprise.
Your application and 10Duke Enterprise need to authenticate the end user who is using your application, and your application needs to be authorized to call 10Duke APIs.
The user authentication and API authorization are based on standard protocols. OpenID Connect (OIDC) is the preferred protocol in most cases. Security Assertion Markup Language (SAML) can be used if your application only needs user authentication and doesn’t need to call 10Duke APIs.
Your application can also handle user authentication directly with an external identity provider, in which case API authorization can be done with JWT Bearer Token Authorization.
For background, see an overview of user authentication in 10Duke Enterprise.
End user authentication
10Duke Enterprise provides identity-based licensing for your application. End user identity is established by authenticating users.
Your application can rely on 10Duke Enterprise to authenticate the end user for you. Your application can direct the user to 10Duke Enterprise for the login, 10Duke Enterprise handles the user authentication, and your application receives information on the authenticated user along with an access token that your application uses for calling 10Duke APIs.
Details of the authentication such as the password policy, multi-factor authentication, and federation can be controlled in 10Duke Enterprise without making changes to your application.
If you (the vendor) use an external identity provider for authenticating users of your application, 10Duke Enterprise can be set up to rely on authentication by the identity provider. Your application can also handle user authentication directly with the external identity provider.
API authorization
10Duke Enterprise uses OpenID Connect (OIDC) / OAuth 2.0 for API authorization. OIDC is a simple identity layer on top of OAuth 2.0. When you use OIDC for user authentication, it always comes with OAuth 2.0 for secure and standards-based API authorization. 10Duke Enterprise grants an access token that your application can use to make authorized requests to 10Duke APIs for the authenticated end user.
If your application authenticates users directly with an external identity provider, JWT Bearer Token Authorization can be used for exchanging an ID token returned by the identity provider to an access token that your application can use to access 10Duke APIs.
If SAML is used for user authentication, your client application won’t be able to call 10Duke APIs.
Note: The authorization of API requests should not be confused with the authorization of accessing your software application: the latter is controlled using licenses and license consumption calls.
10Duke Authentication API
When your application relies on 10Duke Enterprise for user authentication, it delegates authentication to 10Duke Authentication API. Your application implements the user login by sending the user to the Authentication API, which either prompts the user for the login details or sends the user to the identity provider of the user’s organization (when federation has been set up).
In most cases, we recommend that your application uses a web browser for the user login by delegated authentication. This enables secure, standards-based, and fully-featured authentication with OIDC or SAML. Your application can either use the operating system default browser, or it can use an in-app (embedded) browser.
A successful login establishes a user session, which is valid in the browser for 30 days by default. If there’s already a valid session when the login is started, there’s no need for the user to log in again, and the login is completed without any user interaction. Your client application won’t see a difference: 10Duke Enterprise always returns information on the user and an OAuth access token when using OIDC.
Details on how to use the 10Duke Authentication API for delegating authentication are specific to the protocol you choose.
If you choose to use an in-app browser and your application doesn’t have a browser component yet, here are some suggestions:
Language | Framework | Browser component |
---|---|---|
C/C++ | Qt | QtWebView |
Windows | WebView2 | |
Other | Chromium Embedded Framework (CEF) | |
.NET | CefSharp Microsoft.Web.WebView2 |
|
Java | JavaFX | JavaFX WebView |
Any | Windows | WebView2 |
Other | Chromium Embedded Framework (CEF) |
There are some 10Duke client libraries that provide an in-app browser for your application (see information below). You can also contact the 10Duke Integration Support team to discuss other options.
Client libraries
10Duke client libraries provide a simple and flexible way to access the 10Duke API functionality using your preferred language and framework.
If you don’t find a client library that you would need, contact the 10Duke Integration Support team for discussing other options.
See more
See how to connect your client application to 10Duke Enterprise using your chosen protocol: