I’m having an issue with username/password users specifically. When they first log in and get redirected to my authorization landing pag there’s a short accessToken but a long idToken. For example:
access_token=3Iwuh8eyI4-mK9Uv&expires_in=86400&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik4wTXdOa00yTmtWRFF6UXhNRFkw20RVNFJFWXlPRGRHT0VVek1Ea3lNVU13TTBKR1JUTXpNUSJ9.eyJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZW1haWwiOiJqb3Jlbm0rM0BnbWFpbC5jb20iLCJjbGllbnRJRCI6IjB1UGdmeGpZNzd0Q1B0Uzg0UGdMblNPQTVpTnVwWkgyIiwidXBkYXRlZF9hdCI6IjIwMTctMDUtMThUMjI6Mjc6MzQuNzI1WiIsIm5hbWUiOiJqb3Jlbm0rM0BnbWFpbC5jb20iLCJwaWN0dXJlIjoiaHR0cHM6Ly9zLmdyYXZhdGFyLmNvbS9hdmF0YXIvMzllNTU5YzU1OWU2M2I3YTY3MTFkYTEzZjM0M2I4MGM_cz00ODAmcj1wZyZkPWh0dHBzJTNBJTJGJTJGY2RuLmF1dGgwLmNvbSUyRmF2YXRhcnMlMkZqby5wbmciLCJ1c2VyX2lkIjoiYXV0aDB8NTkxZTBhNTYzMWU3N2M3NGRjZGMxYWU3Iiwibmlja25hbWUiOiJqb3Jlbm0rMyIsImlkZW50aXRpZXMiOlt7InVzZXJfaWQiOiI1OTFlMGE1NjMxZTc3Yzc0ZGNkYzFhZTciLCJwcm92aWRlciI6ImF1dGgwIiwiY29ubmVjdGlvbiI6IlVzZXJuYW1lLVBhc3N3b3JkLUF1dGhlbnRpY2F0aW9uIiwiaXNTb2NpYWwiOmZhbHNlfV0sImNyZWF0ZWRfYXQiOiIyMDE3LTA1LTE4VDIwOjU1OjUwLjM5OFoiLCJpc3MiOiJodHRwczovL2pvcmVuLmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1OTFlMGE1NjMxZTc3Yzc0ZGNkYzFhZTciLCJhdWQiOiIwdVBnZnhqWTc3dENQdFM4NFBnTG5TT0E1aU51cFpIMiIsImV4cCI6MTQ5NTE4MjQ1NCwiaWF0IjoxNDk1MTQ2NDU0fQ.SBQcAq1dXpU5XLCkE0WbADNH5AIDZ0KiGNCNO3unsWys5BUnV2Q65wbGrdfWgPDwJcyo80yTaiHTrjW9_7snu08DvRcZdU_IJ4y0o5MKWEuQmWEW4_jbBu5Sm6UGGNxPMJ1JohoGVHGhizA2AQNRDNS4L8pJ06gcPLNuUO8uUZVaRuGlOYG3739iyUTU5YPH058udn0gQUGV_HmYX2ERRgE_KZQH-HiUoUk_08XSqKGpfIRLh_lNp9TLd3QVYTzPpUfB7Vkih2qh-0VEQYy1LcgihKoQkNC7XVspA_B7cDz69IkZHRipSb7Wt_aWoPme6pGh-Y10SaAlHkX45Iu2oQ&token_type=Bearer
Since a real JWT accessToken is what I need, I log the user out when this happens. When they next go to log in it shows a “Last time you logged in with youremail@email.com” dialog, and if I click the email to log in, I get this with a proper accessToken:
access_token=eyJ0eXAiOiJyV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik4wTXdOa00yTmtWRFF6UXhNRFkwT0RVNFJFWXlPRGRHT0VVek1Ea3lNVU13TTBKR1JUTXpNUSJ9.eyJpc3MiOiJodHRwczovL2pvcmVuLmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1OTFlMGE1NjMxZTc3Yzc0ZGNkYzFhZTciLCJhdWQiOlsicnRpc2VydmVyLmhlcm9rdWFwcC5jb20iLCJodHRwczovL2pvcmVuLmF1dGgwLmNvbS91c2VyaW5mbyJdLCJhenAiOiIwdVBnZnhqWTc3dENQdFM4NFBnTG5TT0E1aU51cFpIMiIsImV4cCI6MTQ5NTE1Mzg5NSwiaWF0IjoxNDk1MTQ2Njk1LCJzY29wZSI6Im9wZW5pZCBwcm9maWxlIGVtYWlsIn0.I59otV_vKptcqy43X-b6hgv-41rzjVTKb0KikwcigkYxE3MG3QD1R1EogL_YxQMrtreGT9K5R0MaYUdpPl6gdEnBdmutUrqyRD-SY-hSJQMUjMCn8V3sqcRwhbCHI7NCCLTI9IeZ5lcfpXsQvGASMYo2c8Qg3r3GT2fVw-ee-b0Gfd17njve-b_Q1EXewLtQqn5nQHv-VlS1jtBTkc3vnovdBHH2-xIxJGeYkNaHRNzGah4332NtukZ8WIZbV5cJDP2iGWLA4Zcl0KdsCZKZJFLm1IGwVPXJvzt3KDf0QAEui1gyqkUZhi_TxJ_KuTESoMEftNkOi2j75niokbFnNQ&expires_in=7200&token_type=Bearer&state=Kn6T0yA7fCzV6MaG_sPcaRQiAbXSHGYE
This is only an issue with un/pw logins. Using a google login it works every time.
This is my lock code:
lock = new Auth0Lock('0uPgfxjY12tCweS84PgLnSOA5iNupZH2', 'mydomain.auth0.com', {
auth:
redirectUrl: window.config.baseUrl + 'authenticate'
responseType: 'token'
params:
scope: 'openid profile email'
audience: 'myaudience.com'
})
Any idea what’s going on?
UPDATE (note about formal support for embedded authentication in Lock):
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.
Based on the response type and other parameters being used I’m assuming this is a SPA that wants to perform user authentication and also obtain an access token to call a specific API. The underlying problem with what you’re doing is that the formal documentation for the use of Lock embedded in your own application when wanting to obtain API access tokens is not yet available.
In conclusion, my recommendation is for you to wait for final documentation if you really need to use Lock from within your own application and at the same time request access tokens for your own API.
If Lock within your own application is not a strict requirement then I suggest you consider using Auth0.js v8 which fully supports user authentication and API authorization scenarios and for which there’s already available documentation. More specifically, check the authorize method available.
I was really desperate and could fix authentication using the method mentioned by jmangelo as above.
Thanks, @jmangelo
Any news on this issue? I have the exact same issue with angular and so far it seems that it has something to do with auth0 api.
This happens only when using username & password login… but when you click on last logged in email it works correctly and saves the correct id_token.
I tried this example https://github.com/astanciu/api-spa-sample as it is and still the same exact issue.
So instead of suggesting to try different versions or methods can someone fix the issue in the example above?
thanks
I was really desperate and could fix authentication using the method mentioned by jmangelo as above.
Thanks, @jmangelo
Any news on this issue? I have the exact same issue with angular and so far it seems that it has something to do with auth0 api.
This happens only when using username & password login… but when you click on last logged in email it works correctly and saves the correct id_token.
I tried this example https://github.com/astanciu/api-spa-sample as it is and still the same exact issue.
So instead of suggesting to try different versions or methods can someone fix the issue in the example above?
thanks
It’s still in progress; at this point what you’re trying to do is not fully supported/documented. I can stop mentioning the already supported libraries which can be used as alternatives, but that won’t directly affect the timeline at which it will be supported/documented in Lock and I would also be depriving information from users that can indeed use the already supported methods.
Thanks @jmangelo will try auth0.js v8 till then.
I was seeing the same problem using auth0.js authorize()- the returned access-token was 16 characters long.
I believe the problem was that I had the audience set wrong. If so, I’d consider this a bug - I should have gotten an error.
I was seeing the same problem using auth0.js authorize()- the returned access-token was 16 characters long.
I believe the problem was that I had the audience set wrong. If so, I’d consider this a bug - I should have gotten an error.
Have in mind that it’s valid and acceptable to perform a request only for authentication (no audience) which would mean an opaque token (currently 16 chars) could be returned; there’s nothing wrong in that.
I tried specifying an invalid audience and that does indeed result in a error; at least for the scenario I tried.
Hi @jmangelo . Is this still an issue? I would like to use lock in my SPA and no need to redirect to auth0 login page. Any idea when is going to be available? Thanks
Ditto on a.garcia’s question. Looks like it is still an issue. Using webauth directly works, but in that case must reproduce the lock gui functionality which seems pretty nice.
The work to support Lock with API Authorization is still ongoing so yes, at this time, it’s still an issue. The bulk of the work has been done, however, I don’t have a definitive timeline that I can share.
Thanks @bradflyon and @jmangelo for the quick response! Looking forward to see this working. I will keep using the redirect approach and keep on eye on this. Thanks a good job here 
@jmangelo Appreciate this is still ongoing, I too have the same issue and need to get a JWT back for my access_token when using the Lock widget within a SPA. Given this is an opaque token, is there anyway we can still use this token on our API’s? Do Auth0 have an endpoint that can return a JWT given an opaque token? The nice thing about opaque tokens is the ability to revoke etc, I didn’t think these were supported at present, am I right?
@jmangelo Appreciate this is still ongoing, I too have the same issue and need to get a JWT back for my access_token when using the Lock widget within a SPA. Given this is an opaque token, is there anyway we can still use this token on our API’s? Do Auth0 have an endpoint that can return a JWT given an opaque token? The nice thing about opaque tokens is the ability to revoke etc, I didn’t think these were supported at present, am I right?
At this time, opaque access tokens issued to client apps are meant only in the scenario where the token is for /userinfo endpoint/audience. So no, it’s not currently possible to use that access token with your own API’s. The reason you get an opaque access token even if you tried to ask one for a specific audience is because you likely used Lock in an unsupported way. If we do start to support opaque tokens for your own API’s there will indeed need to be an endpoint where you can get information about the token so that your API can decide to trust it or not, but this is not available.
At this time there is no update, at least not the one you would prefer to read about. The work is still ongoing and there’s not a definitive release date.