Page 1 of 1

Use OpenDental credentials to log into website?

Posted: Wed Mar 08, 2023 6:03 am
by SmileShoppe
Question: We want to develop a web portal that has user/login verification. We want it to validate against the credentials of our OpenDental users using the API.

Is there any way to do this?

Could we update the UserODs PUT method to include passing back "Password" but NOT to update it, but rather validate it.

The results could show:
200 OK - username and password valid so we can grant access to the website.
400 BadRequest (with explanation) - password invalid.
404 NotFound (with explanation) - username invalid.

Something of that sort?

Thanks.

Re: Use OpenDental credentials to log into website?

Posted: Wed Mar 08, 2023 12:20 pm
by SLeon
Good morning,

What is your use case needing to validate Open Dental usernames and passwords? Any application you create should have its own sign in credentials. You would want to do this so you were able to actually manage the credentials (reset password, forgotten passwords, sign in attempts, etc.). This is in addition to obvious security concerns.

Re: Use OpenDental credentials to log into website?

Posted: Thu Mar 09, 2023 9:14 am
by SmileShoppe
We have an automated insurance verification bot. This site would be to access the bot's Dashboard to check on the run status as well as see if there were any errors. Our biller already has access to OpenDental and it would easier for us to tie their login to the Dashboard to their OpenDental login. This way, it's one less thing for us to have to remember to add/remove permissions for.

Thanks.

Re: Use OpenDental credentials to log into website?

Posted: Thu Mar 09, 2023 10:49 am
by allends
As SLeon stated, we recommend our 3rd party developers create their own login systems so they can manage the credentials (reset password, forgotten passwords, sign in attempts, etc.).
We do not have any plans of allowing developers to verify unknown credentials against the Open Dental database to check for validity of passwords and usernames. There are obvious security risks with allowing this functionality. Additionally, the potential headache of offices getting locked out of their accounts (due to incorrect password attempts) is something I would like to avoid.

For those reasons, I am denying this request.