Auth0 multiple client id

[Calion54]

Hello, I'm using auth0 in my project. I have a web app and a mobile app, so there are multiple client id from auth0.

How to put these keys in your library ?

Thank you.

[mcueto]

It's actually unsupported in this moment, BUT i will work this weekend in a solution for it! stay tuned! :D PD: it's also in #17

[Calion54]

Ok ! Thank you for this answer.

[Calion54]

I see the possibility to create a non interactive client from auth0 manager. There are example for flask api but not for django rest. that's bad. There may be a possibility to just use the id client and the secret client to communicate with all other applications.

[Calion54]

I have a solution but I don't know if it's possible. In your settings api, you have a map of object which contains informations (client_id, secret...) You can pass an another header "auth-type": "Android" in your request and when you decode the JWT you find the object with index "auth-type"

So, is it possible to have access of request's header ?

I'm working on this. @mcueto

[mcueto]

@Calion54 thank you!!!!!

Instead of auth-type i would create that parameter as app_code or client_code

I had no time to do this, so sorry and thank you!!!

[Calion54]

Hello @mcueto

I have created a pull request to manage the multiple clients

[mcueto]

Merged to feature/multiple-clients! it would be ideal to figure out how to not broke the old client settings with the new one. After that, if we decide to broke that or provide a fix(or temporal fix), i will merge to development, then a master, then i'll upload it to pipy.

Thank you @Calion54

[mcueto]

i'll close this Issue once merged to master ;)

[Calion54]

Hi,

Why do you want to keep the old settings method? It is enough to propose a version 2.

[mcueto]

Only to not to break it up to the people using it, but as i said, we could break it if we decide to ;) so i listen to you :)

may we break the old config? if you answer is yes, this same week i merge this new feature to the master branch ;)

[Calion54]

I think that the best idea to keep only the new configuration (Manage both would make an illegible code...) I would nevertheless correct and add 2 features :

• Customize the field name of the header
• the new fields is already mandatory even if there is no need for authorization ... it's not normal ... I will correct this before the pull request.

[mcueto]

@Calion54 Thank you!!! :) no problem with that. So we'll keep only the new configuration :)

[mcueto]

Merged!!! thanks :)