POSTIDENT System
Introduction of the Alternative Authentication Method "JWT Bearer Token" for System Accounts on the Standard Connect & Result (SCR) API
In addition to the existing Basic Auth authentication method, Release 34.0 introduces JWT Bearer Token as an alternative authentication method for system accounts on the Standard Connect & Result (SCR) API. Due to its weaker security characteristics, the Basic Auth method will be discontinued in the future. The exact date will be communicated separately.
With the JWT Bearer Token method, you first request a token by submitting an assertion signed with your private key. You then use the returned bearer token to authorize subsequent API requests. Once the token expires, a new token must be requested. The public keys required to verify assertions signed with your private key can either be maintained by the POSTIDENT Service Team for your system account or managed directly in the POSTIDENT Information Portal by a user account with the User Administration role. To configure a public key yourself, open the relevant system account in the User Administration section and click Add New SCR Public Key in the SCR Public Keys section of the Credentials panel. Enter your public key in the dialog that opens and click Save.
Our technical documentation at https://www.postident.de/download will be extended when Release 34.0 is rolled out and will include the key definition as well as an implementation example.
POSTIDENT Apps and SDK
Android App
Additional security mechanisms have been integrated for Android 16 to further protect sensitive customer data against unauthorized access during the identification process.
POSTIDENT by AutoID
The user interfaces within the AutoID process have been revised in several areas and more closely aligned with the other POSTIDENT methods. This particularly affects the method descriptions and the user guidance provided during the capture of ID documents and video selfies.
iOS App
Navigation Structure
The navigation structure within the POSTIDENT app has been simplified and made more intuitive. This provides users with clearer guidance throughout the identification process and a better understanding of their current step as well as the remaining steps.
POSTIDENT E-Signing
A defect related to notification permissions during identification using eID has been resolved.POSTIDENT by AutoID
The user interfaces within the AutoID process have been further optimized and standardized. In addition to revising the method and process descriptions, the screens used for capturing ID documents and video selfies have been modernized to guide users more effectively through the identification process.
Overview of current versions:
| SDK | Version | Date of release | End of official support | New features |
|---|---|---|---|---|
| iOS | 2.17.1 | 27.04.2026 | 27.10.2026 | POSTIDENT by post office
POSTIDENT by eID function
POSTIDENT by AutoID
|
| iOS | 2.18.3 | 10.06.2026 | 10.12.2026 | SDKUIConfigBuilder Class Re enabled We have re enabled the SDKUIConfigBuilder class, allowing you to individually configure the animation behavior during SDK startup and adapt it to your app's requirements. Support for iOS Versions
General Improvements
POSTIDENT via Online ID Function
POSTIDENT by post office
Notice Regarding SSL/TLS Security in the POSTIDENT SDK: We are providing updated certificate and hash value information for the existing SSL/TLS pinning method for the last time. This is due to a planned certificate change in the autumn. From 2027 onwards, we will significantly simplify security: Regular updates of certificate hash values will no longer be required, substantially reducing your maintenance effort. Current adjustments (transition phase) For the POSTIDENT SDK, we are providing updated hash values for the previously used SSL/TLS pinning method for the last time. This adjustment is necessary because the POSTIDENT certificates will be renewed in the autumn.
Future migration to CA certificate pinning From April 2027, the previously used SSL/TLS pinning will be completely replaced by CA certificate pinning at DPDHL level. Your benefits from this change:
To continue using POSTIDENT SDKs, it is necessary to switch to the respective current SDK version no later than April 2027. |
| iOS | 2.19 | exp. CW 30 2026 | Initialization of the Host App in Light or Dark Mode When initializing the SDK, it will now be possible to enforce either Light Mode or Dark Mode via a flag. This can be particularly useful in scenarios where the host app uses a Dark Mode-like design by default. E-Signing For regulatory reasons, it is not permitted that, in cases with multiple signatories, at least two signatories use the same device (smartphone or tablet). Previously, this invalid configuration was only detected at the end of the process. | |
| iOS | 2.20 | exp. cw 40 2026 | Navigation Structure The navigation structure within the POSTIDENT SDK has been simplified and made more intuitive. This provides users with clearer guidance throughout the identification process and a better understanding of their current step as well as the remaining steps. POSTIDENT by AutoID The user interfaces within the AutoID process have been further optimized and standardized. In addition to revising the method and process descriptions, the screens used for capturing ID documents and video selfies have been modernized to guide users more effectively through the identification process | |
| Android | 2.17 | 01.04.2026 | 01.10.2026 | Android 16 Support "Edge-to-Edge"
POSTIDENT by AutoID
SDK Dependency Version Compatibility The POSTIDENT SDK relies on a set of well-established third-party libraries. While these dependencies are declared internally, they are resolved together with the consuming application's dependency graph at build time. To ensure correct behavior, applications integrating this SDK must use compatible versions of the required libraries. Gradle will automatically select the highest compatible version present in the dependency graph. Using significantly older versions than those listed below may lead to build-time resolution failures or unexpected runtime behavior. The SDK is regularly tested against the versions specified below.
|
| Android | 2.18 | 12.06.2026 | 12.12.2026 | Stability improvements
Modernized app design
Notice Regarding SSL/TLS Security in the POSTIDENT SDK: We are providing updated certificate and hash value information for the existing SSL/TLS pinning method for the last time. This is due to a planned certificate change in the autumn. From 2027 onwards, we will significantly simplify security: Regular updates of certificate hash values will no longer be required, substantially reducing your maintenance effort. Current adjustments (transition phase) For the POSTIDENT SDK, we are providing updated hash values for the previously used SSL/TLS pinning method for the last time. This adjustment is necessary because the POSTIDENT certificates will be renewed in the autumn.
Future migration to CA certificate pinning From April 2027, the previously used SSL/TLS pinning will be completely replaced by CA certificate pinning at DPDHL level. Your benefits from this change:
To continue using POSTIDENT SDKs, it is necessary to switch to the respective current SDK version no later than April 2027. |
| Android | 2.19 | exp. CW 30 2026 | UX Improvements
E-Signing For regulatory reasons, it is not permitted that, in cases with multiple signatories, at least two signatories use the same device (smartphone or tablet). Previously, this invalid configuration was only detected at the end of the process. Dependency Version Compatibility OKHttp 4.x The POSTIDENT SDK still uses OkHttp internally, but the SDK now publishes a shaded implementation of OkHttp and Okio so that consuming applications do not need to align their own OkHttp versions with the SDK. This is intentionally done to support customer applications that already use a different OkHttp version or need to upgrade OkHttp on their own schedule. In other words: you can use the OkHttp version that best fits your application without having to force the SDK to the same version. The shaded HTTP client is packaged inside the SDK artifacts, relocated away from the standard okhttp3 / okio package names, and is not exposed as a regular transitive dependency anymore. Integrators should continue to depend only on the published SDK artifacts and should not reference shaded OkHttp classes directly. | |
| Android | 2.20 | exp. cw 40 2026 | Android 16 Additional security mechanisms have been integrated for Android 16 to further protect sensitive customer data against unauthorized access during the identification process. POSTIDENT by AutoID The user interfaces within the AutoID process have been further optimized and standardized. In addition to revising the method and process descriptions, the screens used for capturing ID documents and video selfies have been modernized to guide users more effectively through the identification process. |
Release 35.0:
Rollout of Release 35.0 is scheduled for 10.11.2026.


