Is this plugin discontinued?

No, this one is alive and well!

Can you point me to where you read that? I just want to make sure we’re not driving anyone away. I’m sure if you have the question, someone else has as well.

https://auth0.com/docs/cms/wordpress/jwt-authentication
There is also this discussion on your community board:
https://community.auth0.com/t/can-users-to-create-posts-using-the-wordpress-api-if-authenticated-with-wordpress-auth0/19625

I was reviewing how your service works when I encountered those. I can see why you’d want to clear up any misunderstandings…
FWIW, it would be a very nasty experience to rely on a plugin for such core functionality and then find it discontinued.

A Few Questions about this Plugin
We have a membership site where we use GForms and S2 Member for onboarding, membership management and content restriction. We want to create a new, non-WP site for our journals. The Journal Site will be under a subdomain. Some of the journals will be free, others will be subscription based. I’d like to continue using our current site to onboard people for the Subscription-based Journals (using GForms). I.e. when someone purchases a journal (or multiple), they would get a login to our current site and a code(s) for the journal(s) they subscribe to. We’d put the codes in a dedicated table in the DB, or JSON or YAML – whatever is secure and makes sense.

Would Auth0 give us the capability to let them login from both the Original Site and the Journal Site using the same login/pwd?
Could we also pass the codes that would allow them to access their subscriptions?
Could they switch between the sites without have to re-enter their login info?
Would this affect the native WP login system for our current users?
The WP roles of our current members is “s2Member Level 1”. Is your authentication role dependent? I.e. if a current member purchases a subscription, would that role interfere with authentication across the sites?
Thanks!

• This reply was modified 5 years, 9 months ago by pixeldroid.

FWIW, it would be a very nasty experience to rely on a plugin for such core functionality and then find it discontinued.

Absolutely. This one is not going anywhere anytime soon. The JWT one duplicates functionality in another plugin that’s out there so it was deemed unnecessary. We’re in the initial steps of a guide for JWT auth with WordPress, FYI.

Thank you for the thorough description of your use case here. I’ll provide as much information as possible to help you make your decision. I’ll focus on authentication here as the rest of how the system works is up to you.

> Would Auth0 give us the capability to let them login from both the Original Site and the Journal Site using the same login/pwd?

Yes, that’s an important component of centralized users. You can also use single sign-on (SSO) to log users in automatically if they have already logged into one of the other sites in the network.

> Could we also pass the codes that would allow them to access their subscriptions?

You can use metadata for the user to store anything you’d like. That could be either accessed as a chunk of JSON on each login if there are multiple values needed or added to the profile data specifically with a custom claim.

> Could they switch between the sites without have to re-enter their login info?

Yes, that would be SSO. Depending on how you want it to work, you’ll need to check Auth0 for a session if you want to log someone in automatically. You can do that a few different ways.

> Would this affect the native WP login system for our current users?

I’m not totally clear on what you’re asking here. The native login system is replaced with Auth0 but your users will remain. You can [automatically migrate](https://auth0.com/docs/users/guides/configure-automatic-migration) users or you can have them signup with Auth0 and they will be associated with their original WordPress account by email.

> The WP roles of our current members is “s2Member Level 1”. Is your authentication role dependent?

No, we don’t do anything with roles. However default roles are managed remains. We have not checked compatibility with that plugin specifically, though, so can’t guarantee they work together. For the most part, everything we’re doing in the plugin follows the “WordPress Way” and we’re happy to address it if not.

Hope that helps!

>I’m not totally clear on what you’re asking here. The native login system is replaced with Auth0 but your users will remain.

Thanks for your thorough answer, let me expand on the login question:
When people register for an event or purchase a membership we collect other information – e.g. profession, certifications, etc. Also, custom codes for our membership software (S2 Member) are added to their user record. We use these codes to restrict content for various membership types. All of this is done via Gravity Forms and a mu-plugin. In addition, the registration form sends a variety of custom notifications – to me, to the new user, sometimes to our event coordinators. This is the core piece of our infrastructure. Is it possible to use your plugin for login but not for registration? If not, is it possible to incorporate the Auth plugin functionality into a Gravity form (even if it requires custom code)? Otherwise, using your plugin for onboarding, we’d need to make it a 2 step process:

1) Register a member (user).
2) Make the purchase via gravity forms to complete the onboarding, which would require some rewiring.

That’s not necessarily a deal breaker, but it’d be nice to keep registration as simple as possible. It took some time to get it working this smoothly ??
You can see a registration form here: https://lacted.org/breastfeeding-educator-registration/
Thanks.

• This reply was modified 5 years, 9 months ago by pixeldroid.

Thank you for the clarification!

Is it possible to use your plugin for login but not for registration?

Possible, yes, but you’d be leaving a key part of your authentication unprotected. The way Auth0 works the best is to have everything involving credentials handled on our infrastructure.

That said, if you wanted a custom registration page to create a user on Auth0, your custom code would need to handle:

1. Creating the user (using the included \WP_Auth0_Api_Client::signup_user() method or the signup endpoint)
2. Associating the Auth0 user to the WordPress user (see the \WP_Auth0_UsersRepo::update_auth0_object() method for how that’s done internally)

One thing to note here if you go down this road … be careful with the email_verified flag for the user. If you’re doing that already (sending an email with a link to verify or similar), make sure you set the flag. If not, leave that up to Auth0 to handle.

> If not, is it possible to incorporate the Auth0 plugin functionality into a Gravity form (even if it requires custom code)?

That would be more of less the above. If you need to retain the current custom registration form capability, then do the above. If, instead, you want to protect registration as well, you could:

1. Redirect to the Auth0 hosted page to register
2. When the user returns, let the Auth0 plugin handle the user creation
3. Once that’s complete, use the auth0_user_login hook to redirect to the Gravity form to collect additional information. At this point the user will be logged in so you can use their email, Gravatar, etc to pre-populate the form.

That’s basically what you outlined at the end of your post here.

So, again, you could do it either way but we’d recommend the latter option to integrate the Auth0 service more completely.

Let me know if there’s anything else!

I like your final recommendation.
It sounds like this could be a great tool for us.
I’m going to setup a test.
Thanks again.