Hello,
I've updated to the .NET 200.6 SDK and am noticing a number of deprecations concerning OAuth classes. Does the .NET team have an up-to-date sample that shows best practices for a client application logging a user in via OAuth? If so, I would appreciate a pointer as I'm not finding the relevant bits.
[EDIT] I'm talking about the deprecations listed here, specifically this info:
OAuthUserCredential : A new type that provides secure, refreshable access tokens for accessing protected services using the "authorization code" workflow. This class replaces OAuthTokenCredential as the preferred OAuth 2.0 approach for user authentication, and needs an OAuthUserConfiguration to be registered instead of ServerInfo.
Thanks
MQ
Solved! Go to Solution.
Sorry we're still working on updating the doc and blog on this. For now, feel free to ask questions here. You can also look at the changes made for one of the demo apps here: https://github.com/Esri/arcgis-maps-sdk-dotnet-demos/commit/a9d97dbb60728af8515a165108c50d9ce3ae192e
Bottom line is the change is just a simplification around how you register the OAuth configuration.
Sorry we're still working on updating the doc and blog on this. For now, feel free to ask questions here. You can also look at the changes made for one of the demo apps here: https://github.com/Esri/arcgis-maps-sdk-dotnet-demos/commit/a9d97dbb60728af8515a165108c50d9ce3ae192e
Bottom line is the change is just a simplification around how you register the OAuth configuration.
Thanks Morten. I think I'll wait on a proper sample. I realize the changes are meant to be a simplification of the previous methodology, but I'm actually finding the changes quite confusing and existing documentation pretty sparse. 🙃
No problem. You're fine to continue using the old ones until the next major release.
The new classes are mostly there because we're working towards a common authentication codebase used across all the maps sdk platforms to improve consistency, faster improvements and only having to make fixes in one place (Swift and Kotlin SDKs already use it). That common underlying codebase is slightly different / modernized and we're building the design to match that before fully switching over in the next major release and removing the deprecated classes. So as long as you move over before that switch, you'll be fine.