At this moment, using Lock embedded in your own application alongside OIDC compliance or API authorization (aka audience parameter) is not yet fully supported nor documented.
We are still completing the work needed to have that possibility and when that is available the documentation will mention this situation. For now, Auth0.js v8 with a redirect to the hosted login page is the available and recommended way to leverage API Authorization.
Be advised that may work for your particular use case, but since it’s not documented it’s also not formally supported and may change (including breaking changes) until a final version is available. Personally, I would not recommend its use until it is documented.
Good to know. However, as there is no way how to change the URL of the hosted login page we used this workaround. To be honest, this workaround kept us from abandoning Auth0. Would please notify us in case there where some breaking changes?
@jmangelo So my understanding is that it is not possible to use API Authorization with Lock.
If this is true, may I kindly suggest that you WRITE THIS IN BOLD in the documentation. For instance here and link text
@jmangelo So my understanding is that it is not possible to use API Authorization with Lock. If this is true, may I kindly suggest that you WRITE THIS IN BOLD in the documentation.
@jmangelo So my understanding is that it is not possible to use API Authorization with Lock. If this is true, may I kindly suggest that you WRITE THIS IN BOLD in the documentation.
It’s not yet documented so as I mentioned I would not consider a supported scenario using Lock in your own application alongside API Authorization. The quickstarts should be showing how to use this feature with Auth0.js (v8) and the hosted login page.
@jmangelo just to make sure we’re on the same line. I suggest you make it highly explicit that Lock and Api Authorization should not be used together so people don’t loose 2 days trying to understand why it doesn’t work.
It’s even better if you give the right scenario, but please update the doc.
I’m sure you have tons of work and this probably explains why you ship incompatible client and server libraries, but at least you should make sure you make it clear in the doc when it’s the case.
hi @jmangelo . I got the same issue here. My project require a Lock embedded Login into our Single Page Application but when I get the token the audience always is the clientID of this application. I tried to add the option auth: {params: {audience: 'xxxxxxx'}} into the Lock but it is not work so I can’t use this token to request the APIs.
Will there be a formal way to embedded the Lock Login with the correct audience so that I can use it to request access to the APIs succesfully?
Thanks
hi @jmangelo . I got the same issue here. My project require a Lock embedded Login into our Single Page Application but when I get the token the audience always is the clientID of this application. I tried to add the option auth: {params: {audience: 'xxxxxxx'}} into the Lock but it is not work so I can’t use this token to request the APIs.
Will there be a formal way to embedded the Lock Login with the correct audience so that I can use it to request access to the APIs succesfully?
Thanks
There is work being done to allow to use Lock within the client application and still get an access token with an audience suitable to call your own API’s. However, at this time there’s still no definitive release date. If I had to guess, I would say the next months.