Auth0 Home Blog Docs

Using Lock widget for Username-Password-Authentication connection, unable to get JWT access token

jwt
access-token

#1

Hi guys,

I am using the Lock 10.13 widget to authenticate and get id tokens and access tokens. I’ve successfully enabled Google, Facebook and Twitter connections to return back full JWT access tokens, but when using the Username-Password-Authentication connection for login, I only ever get back short, opaque access tokens. The configuration params I’m passing the Auth0Lock instance is as follows:

options = {
    clientID: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
    domain: 'xxxxxxxx.auth0.com',
    auth: {
      responseType: 'id_token token',
      audience: 'https://stoic.xxxxxxxx.com/',
      params: {
        responseType: 'id_token token', // For social, must be here.
        audience: 'https://stoic.xxxxxxxxxx.com/', // For social, must be here.
        scope: 'openid email picture user_metadata app_metadata access:xxxxxx_api' // offline_access.
      }
    },

    loginAfterSignUp: false // Wait for email verification.
};

I get this kind of response when using the Username-Password-Authentication connection in the widget.

{accessToken: "p2DaEIo4zvogf-vK", idToken: "eyJ0eXAiOiJKV1QiLCxxxxxxxxxxxxxxxxsImtpZCI6Ik56Zz…MaJwNAbr6gupxsG4G44PnAInPyx46Jxze-osBvlI3jqRuooQw", idTokenPayload: Object, refreshToken: undefined, state: undefined}

What else do I need to do to get my connection to return back JWT access tokens, instead of the short token?

Cheers,
Mark


#2

Hey Mark!

We highly recommend against allowing users to enter their credentials on the client (your app) itself instead of on the Authorization Server (on Auth0) or on the external Identity-Provider. This is because it’s a significantly more secure approach - vulnerabilities in client applications won’t necessarily compromise your user credentials, you’ll have better CSRF protection, and full support for SSO.

Our recommended approach is to use Auth0’s Hosted Pages - you can customized the Hosted Login Page as you please visually and on your client, your code simplifies to just the following:

webAuth.authorize({
  audience: 'https://mystore.com/api/v2',
  scope: 'read:order write:order',
  responseType: 'token',
  redirectUri: 'https://example.com/auth/callback'
});

See the auth0.js repo and our docs for more info.


For some additional information; the reason you’re seeing the behavior that you see is because currently, Lock’s username-password based authentication doesn’t use the new API Authorization features.
We’re working on more secure alternatives which will support this scenario with the API Authorization features too, but even with the upcoming alternatives, we will continue to recommend Hosted Pages for the most secure auth flows.


#3

Internal comment: I’m avoiding mention of the oidcConformant flag and avoiding mentioning embedded login approaches as per this


#4

OK, thanks for the info. So it’s not recommended to use the Lock widget on my own site for entering in email/username and passwords (using the Username-Password-Authentication connection)?

I actually did figure out how to simulate the OAuth flow using the oidcConformant flag, so I’m now getting compliant OAuth responses and access_token values. But I don’t want to do it the wrong way.


#5

OK, thanks for the info. So it’s not recommended to use the Lock widget on my own site for entering in email/username and passwords (using the Username-Password-Authentication connection)?

I actually did figure out how to simulate the OAuth flow using the oidcConformant flag, so I’m now getting compliant OAuth responses and access_token values. But I don’t want to do it the wrong way.


#6

The oidcConformant flag allows you to use Auth0’s extension to the Resource Owner password grant on the client-side - however, the password grant is meant for highly-trusted confidential clients (i.e. ones that can be fully trusted to keep user credentials and client secrets safe). Security-wise, unless you have a very compelling reason, there’s no reason to take that risk - it’s much easier and more secure to use the Hosted Login Page.


#7

We are also using OIDC conformant flag true and seeing this issue with Username-Password-Authentication connections. Can you please advise on how we can use Username-Password-Authentication for OIDC conformant connections?


#8

We are also using OIDC conformant flag true and seeing this issue with Username-Password-Authentication connections. Can you please advise on how we can use Username-Password-Authentication for OIDC conformant connections?


#9

We are also using OIDC conformant flag true and seeing this issue with Username-Password-Authentication connections. Can you please advise on how we can use Username-Password-Authentication for OIDC conformant connections?


#10

We are also using OIDC conformant flag true and seeing this issue with Username-Password-Authentication connections. Can you please advise on how we can use Username-Password-Authentication for OIDC conformant connections?


#11