AAD authentication by providing access token

[RudraNirvan]

Is your feature request related to a problem? Please describe.
The current AAD authentication does not allow the client to submit an auth token directly to connect to a database. Instead it provides ways to generate the token and then connect to the DB.

Describe the solution you'd like
Supply the auth token in the connection string to connect to the DB.

Describe alternatives you've considered
The existing mechanism is the alternative, however, it does not allow one to directly submit an auth token.

Additional context
None.

---

Issue cloned from: denisenkom#752

[shueybubbles]

I can't 100% speak for the original owners' intent, but I think the use of the specific connector today is based on a few considerations:

• A connection string is inherently static, while a token is inherently dynamic.
• The driver packages are designed to minimize the dependencies an app brings in based on its use case. If an app doesn't need "full" AAD, and it has some external mechanism to get a token, it can simply use the existing token-based connector instead of the azuread connector. How it gets the actual token at runtime is up to the application.
• Early binding to the token in the connection string doesn't align to many real-world scenarios, as most tokens expire within an hour while the app can run some arbitrary amount of time. Using a callback allows the app to provide non-expired tokens when needed.

There's a similar split between SSPI/integrated authentication and AAD authentication in the driver already. Apps using integrated authentication use a different connector than apps using AAD authentication.

This model is somewhat unlike that of other SQL client drivers like ADO.Net or ODBC where the connection string provides every possible parameter for every possible connection type. However, I don't know of any other SQL client driver that includes the token in the connection string. In ADO.Net you can programmatically set the token on the SqlConnection object or you can implement a SqlAuthenticationProvider callback to provide the token on connect.

[RudraNirvan]

@shueybubbles how about this then:

Interface for the clients

mssqlConnector, err := azuread.NewConnectorWithAccessTokenProvider(connString, tokenProvider)
conn := sql.OpenDB(mssqlConnector)

Changes in the driver

func NewConnectorWithAccessTokenProvider(dsn string, tokenProvider func(ctx context.Context) (string, error)) (*mssql.Connector, error) {

	config, err := parse(dsn)
	if err != nil {
		return nil, err
	}

	return mssql.NewSecurityTokenConnector(
		config.mssqlConfig,
		tokenProvider,
	)
}

The above change goes next to azuread.NewConnector(...). Refer:

go-mssqldb/azuread/driver.go

Line 34 in f21bac1

func NewConnector(dsn string) (*mssql.Connector, error) {

I've tested this change, sounds good?

[shueybubbles]

Why wouldn't the app just use msdsn.Parse and mssql.NewSecurityTokenConnector directly instead of routing it through azuread and pulling in that extra code? We could put this new method in mssql instead just to make the Parse call on behalf of the client, I guess.

[RudraNirvan]

@shueybubbles done. PTAL at PR #26.

[shueybubbles]

thx. Our team reviews issues and PRs on Thursdays, stay tuned.

[RudraNirvan]

Sure, btw, how can I re-sign the CLA? I tried to create a new PR, but it took the CLA signature of the older PR.

[RudraNirvan]

@shueybubbles ping, didn't get a review on this.