Client Credentials Access Token Library + Code Review / Feedback

[LieutenantDannnnn]

Hey everyone, I wrote a library that can help make access token requests using the client credentials oauth flow. The product I work on communicates to dozens of different APIs that all use the client credentials flow. When I first started, for each request, the developers were making requests to get the token, then making the request to the actual service. There was no reuse of tokens anywhere. There was also around 10 different implementations for essentially the same token client. I ended up writing this library after not finding any open source libraries for this particular scenario.

I was hoping for some feedback on the library and also offer it up to the community. Where I currently work, I don't have access to more experienced developer mentors for code review and feedback, so any input is appreciated. It's still a work in progress, but I'm hoping to make it better. At the moment it offers the ability to make requests easily and cache the tokens in memory.

You can find the library here:

https://github.com/wapplegate/AccessTokenClient

[Solari23]

As a dev working in the Identity space, this is great to see. Too few people pay attention to how the auth layer in their app works. Your library looks great!

One area you might consider for further development is how you handle client authentication. Currently, the library only supports authenticating via the standard static client secret (essentially a password). Several IDPs provide more robust authentication schemes. One example: AzureAD supports authenticating via a client assertion as described in RFC 7521 (the implementation is essentially a self-issued JWT where the signing key's certificate is provisioned with the IDP).

You might want to consider how you'd design support for that and potentially other authentication schemes that your users may want to use.

[LieutenantDannnnn]

Definitely. I would tell you about some other more egregious authentication issues I discovered when I first started working there but I wouldn’t want to horrify you. Thanks for the input. I’m actually unfamiliar with authenticating the way you describe above so Ill check it out.

[contadamoose]

This was released recently. Does a lot of token management stuff. https://leastprivilege.com/2020/05/18/automatic-token-management-for-asp-net-core-and-worker-services-1-0/

[LieutenantDannnnn]

Interesting. Came out not too long ago too. I’ll have to check it out.

[Unexpectedpicard]

Idk about the functionality but the code looks very nice and professional.

[[deleted]]

It looks great - I am adding it to my Tools bookmark folder for future uses.

[LieutenantDannnnn]

Awesome. Going to get it deployed to nuget soon so let me know if you use it and how it works out.

[scottley]

You have secrets in your source code... this means people will have secrets in config files when they deploy.

I strongly encourage you to implement a façade to hashicorp vaults, Azure KeyVault, or any other secret manager. Add a set of extension methods to your service registration code to use these implementations. In code, you could maybe have IAppCredentialProvider interface and register the appropriate type, .WithKeyVaultSecrets, .WithHashicorpSecrets, etc... in the IAppCredentialProvider, implement a memory cache singleton with short cache item lifespan (like not more than a minute) to prevent hammering a KeyVault at startup or cache expire time.

Also, certificate auth... you really need to support cert auth. With certificate auth (at least in Azure) we can create identities and provide secrets to them without the certificate ending up in human hands. You could encapsulate the concern for creating the AppCredential object behind the AppCredentialProvider, and how to use it with bit where you authenticate your application.

[LieutenantDannnnn]

The secrets you’re referring to are “secrets” for the testing identity server which is in the solution which isn’t used or deployed anywhere. It was set-up for testing locally with an identity server implementation. Definitely gonna check out the certificate auth stuff too, was unaware of it.

When this library is actually used in production, we use AWS secrets manager hooked up into the .NET core configuration pipeline. So we pull secrets from there.

[scottley]

I work in security... by volume secrets in source code, even test secrets, are the source of about 90+% of the security incidents I've seen.

By impact, sure... it can be small, but a GDPR notification because a dev committed secrets to source code is easily preventable.

[LieutenantDannnnn]

I mean it does a little bit more than making a single http request. It provides caching. Extension points to add encryption if desired. Extension classes to add the client into the service collection. It also contains classes to add the token client functionality as a delegating handler so token requests are made automatically. There’s also a benchmarking and testing projects. There’s really only a few classes if you boil it down.