Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Identity] TokenCache update. #14064

Merged
merged 13 commits into from
Mar 22, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 77 additions & 27 deletions common/config/rush/pnpm-lock.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

1 change: 1 addition & 0 deletions sdk/identity/identity/.gitignore
Original file line number Diff line number Diff line change
@@ -1 +1,2 @@
src/**/*.js
!test/assets/cert.pem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's in this PEM?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the literal PEM that I used to record this test. It's no longer associated with my account.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if it gets flagged by credscan?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test recordings should be sanitizing out the client assertion that gets sent which contains the signature. If you do this you can use any arbitrary cert for playback, and not need to use the same cert which was used to record. This will reduce the risk of committing a cert which could still be used to authenticate. We use such "dummy" certs in .NET (both PFX and PEM) and I have not seen them get flagged by credscan.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cert I use is not associated to any account, but it's a valid cert. I could replace it with the same exact cert that .Net uses, if that helps.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as long as the cert is not capable of authenticating any account it's fine.

16 changes: 16 additions & 0 deletions sdk/identity/identity/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,26 @@

This release continues with the changes from `1.2.4` and `1.2.4-beta.1`.

- The `getToken` methods will now never return `null`. If a token is not available, we will return a rejected promise.
- `DefaultAzureCredential`'s implementation for browsers was simplified to throw a simple error instead of trying credentials that were already not supported for the browser.
- Breaking Change: `InteractiveBrowserCredential` for the browser now requires the client ID to be provided.
- Documentation was added to elaborate on how to configure an AAD application to support `InteractiveBrowserCredential`.
- Replaced the use of the 'express' module with a Node-native http server, shrinking the resulting identity module considerably
- Updated `@azure/msal-node-extensions` to [1.0.0-alpha.6](https://www.npmjs.com/package/@azure/msal-node-extensions/v/1.0.0-alpha.6).
- Refactored our use of MSAL to better centralize the handling of inputs, outputs and errors.
- Migrated the `InteractiveBrowserCredential`, `DeviceCodeCredential`, `ClientSecretCredential`, `ClientCertificateCredential` and `UsernamePasswordCredential` to the latest MSAL.
- This update improves caching of tokens, significantly reducing the number of network requests.
- Credentials `InteractiveBrowserCredential`, `DeviceCodeCredential` and `UsernamePasswordCredential` now can:
- Receive a `tokenCachePersistenceOptions` parameter to specify persitence caching of the credentials used to authenticate. This feature uses DPAPI on Windows, it tries to use the Keychain on OSX and the Keyring on Linux, and if the user sets `allowUnencryptedStorage` to true in the `tokenCachePersistenceOptions`, it allows to fall back to an unprotected file if neither the Keychain nor the Keyring are available.
- As part of this beta, this feature is only supported in Node 10, 12 and 14.
- Receive an `authenticationRecord` from a previous authentication on their constructors, which skips the initial request altogether.
- Receive a `disableAutomaticAuthentication` setting on the constructor, which stops `getToken` from requesting the user to authenticate manually.
- An `authenticate()` method has been added besides the `getToken()` method.
- The `authenticate()` method returns an `AuthenticationRecord` which can be serialized into strings with their property `serialize()`. To later deserialize from string into an `AuthenticationRecord`, use the new function `deserializeAuthenticationRecord()`.
- If `disableAutomaticAuthentication` is set on the constructor of these credentials, developers can now control when to manually authenticate by calling to these credential's `authenticate()` method.
- `DeviceCodeCredential` now can receive its optional parameters as a single parameter object.
- Breaking change: `InteractiveBrowserCredential` now only has `loginStyle` and `flow` in the optional parameters when the credential is bundled for browsers. This reflects the intended behavior.
- Breaking change: Removed the `postLogoutRedirectUri` from the optional properties of the `InteractiveBrowserCredential`.

## 1.2.4 (2021-03-08)

Expand Down
Loading