Auth0 Home Blog Docs

Auth0 Lock returning short access token

access-token
auth0lock
weapi

#1

I am using Auth0 Lock in my Ionic 2 app and trying access .Net core web api securly. However I always get very short access token (which looks like refresh token). Here is my code:

options = {
    //allowLogin: false,
    auth: {
      redirect: false,
      params: {
        scope: 'openid offline_access',
      },
      sso: false
    },
    theme: {
      logo: this.logo,
      //labeledSubmitButton: false,
      primaryColor: '#1295a1'
    },
    languageDictionary: {
      title: "Tittle"
    },
  };
  lock = new Auth0Lock(Auth0Vars.AUTH0_CLIENT_ID, Auth0Vars.AUTH0_DOMAIN, this.options);

this.lock.on('authenticated', authResult => {
      this.storage.set('id_token', authResult.idToken);
      this.storage.set('access_token', authResult.accessToken);
});

#2

UPDATE:

As of Lock version 10.22 the possibility to use Lock in an embedded authentication scenario has now formal support. You should read more about it in Lock reference docs and also cross-origin authentication.


At this time the use of Lock embedded directly within the client application implies that you will not be able to leverage OIDC conformance and/or API Authorization functionality. The API Authorization feature would be what would be required in order to obtain an access token suitable to call your own API registered at Auth0. We’re working on enabling additional flows what would allow the usage of Lock (within the client application itself) and the usage of these feature, but at this time they are not yet available.

You also mention that this is an Ionic 2 application so if you haven’t done so already you can check the associated quickstart that leverages the auth0-cordova library to implement the PKCE flow that redirects the user to the hosted login page, where they authenticate. This flow would support API Authorization so what you’re trying to achieve would be immediately available.


#3

When will this be ready? Now it is annoying to have to login twice every time a user tries to login.

The first login returns a short auth token. the second login returns a long auth token


#4

When will this be ready? Now it is annoying to have to login twice every time a user tries to login.

The first login returns a short auth token. the second login returns a long auth token


#5

There’s no definitive date that I can share at this time.


#6

I don’t understand why the second login works and returns the full Access Token while the first one returns a short token.

Why does second step even work? And if it works what is stopping it from combining step 1 and 2 into a single step?


#7

The fact the second request worked was because due to an existing session the second request could be processed differently. However, this was an implementation detail of the first request and it was not formally supported. As of Lock version 10.22 the possibility to use Lock in an embedded authentication scenario has now formal support. You should read more about it in Lock reference docs and also cross-origin authentication.


#8