tedious: Unable to connect to Azure SQL using Azure AD Credentials

type: azure-active-directory-default (DefaultAzureCredential) has been released on Tedious version 14.4.0

We’ve just merged PR #1365 which adds support for DefaultAzureCredential, but it hasn’t been released to NPM yet. In the meantime, you could continue using azure-active-directory-access-token as a workaround.

Also, could give this comment a look to see if that solves your issue.

@jamesderrick Thank you SO much for sharing this hack! It worked for me as well, so now I don’t have to check the env to decide whether to use azure-active-directory-password or azure-active-directory-msi-app-service.

Yeah DefaultAzureCredential would be great. I’ve actually been using that already but to generate an access token and using the access token to connect to the Azure SQL

const credential = new DefaultAzureCredential()
const {token} = await credential.getToken("https://database.windows.net/.default")

const config = {
...
  authentication: {
    type: 'azure-active-directory-access-token',
    options: {
      token: token
    }
  }
...
}

I would definitely like to use DefaultAzureCredential as soon as possible too, to work around some of these more complicated issues.

Hi @nihonjinboy85 , We will always try to keep the github.io page for tedious up to date, so this documentation should be users’ first choice for utilizing tedious. In terms of the other question, I remember that we recently merged a change that allows users to use DefaultAzureCredential provided by the @azure/identity. I will double-check to confirm this, and the documentation will be updated soon as well.

I’ve also checked this document as guide. It doesn’t mention Azure AD authentication so I’m finding it quite hard to find an up-to-date document for how to use AAD with NodeJS Microsoft Guide

Hi @jamesderrick, for the clientId, on the tedious side, we used to hardcode a client from a registered application that we set up internally. We recently found out that is not a good practice to do it this way, the best practice should be: users set up their own registered applications and grab their own client id and pass that into tedious via a connection config we provided call clinetId. That is why we have a warning message here to notify users ahead of about this behavior change. There is a doc from the Microsoft site for registered app set up. During this transition period, we still allow users to use the hardcoded clinetId for now, but it will be removed entirely in future major releases.

For the “Security token could not be authenticated or authorized” error, it should be caused that you are missing a tendenID from the connection config. If you do not provide a tenantId here, a default id “common” will be used here, which does not work with your current server-side setup.

You can provide you tenantId like this:

const config = {
    authentication: {
        options: {
            userName: 'userID', // update me
            password: '' ,// update me
            tenantId: '< tenantId >' ,// update me
        },
        type: 'azure-active-directory-password'
    },
    server: 'ServerName', // update me
    options: {
        database: 'DBName', //update me
        encrypt: true
}