Auth0 Home Blog Docs

iOS CredentialsManager not retrieving with non-OIDC



I am using the Lock.swift (v2.3.1) and Auth0.Swift (v1.7.1) SDKs for iOS 9+. In the documentation for Auth0.Swift, it suggests that the class CredentialsManager can be used to store the Credentials object and retrieve it again later. This feature works correctly when I use Lock with OIDC conformance set to true. However, it does not behave as expected when OIDC conformance is set to false.

Below is a working example:

  .withConnections { (connections: inout ConnectionBuildable) in 
    connections.database(name: "Username-Password-Authentication", requiresUsername: true)
  .withOptions { (options: inout OptionBuildable) in
    options.scope = "openid profile user_metadata app_metadata" // some custom scopes
    options.oidcConformant = true
  .onAuth { (credentials: Credentials) in
    let credentialsManager = CredentialsManager(authentication: Auth0.authentication())
    let isCredentialsStored = credentials)
    if isCredentialsStored {
      print("Credentials saved: \(credentials.debugDescription)")
      let isValid = self.credentialsManager.hasValid()
      if isValid {
      } else {
      credentialsManager.credentials { (error: CredentialsManagerError?, credentials: Credentials?) in
        if let error = error {
          print("Failed to instantly retrieve the credentials with error: \(error)")

Output ( oidcConformant = true ):

Credentials saved: <A0Credentials: 0x14d2a930>

Output ( oidcConformant = false ):

Credentials saved: <A0Credentials: 0x15dc0a10>
Failed to instantly retrieve the credentials with error: noCredentials

Note that when oidcConformant = false, the variable in the above example, isCredentialsStored, still evaluates as true! However, the hasValid and credentials method in CredentialsManager both fail.

Is there a reason why the credentials manager cannot retrieve a stored credential when OIDC conformance is set to false? How can I store the Credentials object while using non-OIDC conformance?


Purely from reading the code (aka I did not run it to prove this theory) it seems that what triggers that situation is that in OIDC mode the response will contain an expires_in parameter in accordance to the specification and running Lock in non-OIDC mode will call a different endpoint that does return the previously mentioned parameter.

The above will then mean that the hasValid and credentials calls behave like that because they can’t ensure that the credentials are valid, due to lack of expiration information, and as such return false and no credentials respectively even though there is credentials data stored.

Also from the code, you could try changing the configuration to also request refresh tokens as they are also contemplated in the logic available for hasValid and credentials, however, the recommendation is for you to use OIDC mode and as such this would be a non-issue.


This utility class is designed for use with OIDC conformance, in regards to hasValid the non oidc conformant credentials are most likely missing the expiresIn value.
Credentials Manager -> hasValid()

If you wish to use the CredentialsManager you should use OIDC Conformance, the method used to renew the token also requires this. If you wish to enable a refresh_token you should add the offline_access scope.