I have a solution based on an IoT PaaS that provides oauth2 and openIDC client functionality, but not provider functionality. I want to make an Alexa Skill and that requires oauth provider-side funtionality. Can I use Auth0 to host a login page, check entered credentials against my IoT platform in real-time, issue authorization codes/access tokens/refresh tokens based on that initial auth with the IoT platform?
If this is not possible as described, how close can I get? Maybe after a user migration/sync I can use Auth0 exclusively in this flow?
If you already have a custom user store that supports username/email and password authentication then the quickest way to integrate with Auth0 would be to use a custom database connection. With a custom database connection you would implement Node.js scripts responsible for validating the received user credentials; these scripts could call into your existing user store for end-user authentication.
The only part that would be your responsibility would be credential validation, then Auth0 would take it from there and enable OpenID Connect and OAuth2 compatible responses. You could even configure your custom database connection to migrate user credentials to Auth0 which would mean at a certain point in time you would not have to continue to have a separate user credentials store.
You can read more about these approaches at:
@jmangelo : just so I’m clear, I understand how Auth0 can host a login page, upon POST use the creds through a “custom database connection” to do auth with my system, then generate an authorization code for Alexa. What I don’t get is a week later when the original session with my system has expired and re-auth is required to interact with my system, does Auth0 have a representation of the user internally that saves username/password to replay that login and get a new session? Also how does the JWT from my system get to the Alexa skill so that I can interact with my system from the lambda?
If you enabled user migration then the second time the user actively authenticates (provides username and password) the credentials would be validated within Auth0 and without a call to the external store associated with the custom database connection. In relation to your last point, I might be missing something, but with this approach the only entity issuing tokens will be Auth0 and the tokens will be delivered to the client application according to the protocol in question (OIDC/OAuth2).