是否可以从Azure样本Azure Active Directory OpenId Connect使用NaiveSessionCache [英] Is it OK to use NaiveSessionCache from Azure-Samples Azure Active Directory OpenId Connect

问题描述

我们正在编写类似于
Azure-Samples / active-directory-dotnet-webapp-webapi-openidconnect

该示例包括 NaiveSessionCache.cs ，它将访问令牌存储在UserObjectId的ASP.NET会话状态。
该代码看起来合理，但是我对天真这个名称感到担忧。

The sample includes NaiveSessionCache.cs, which stores the access token in the ASP.NET Session state for UserObjectId. The code looks reasonable, but I have concerns with regards to the name "Naive".

有什么理由不应该在生产中使用它？

Are there any reasons why I should not use it in production?

Vittorio Bertocci的文章 ADAL v2中的新令牌缓存，描述了
FileCache（用于桌面应用程序）
和数据库EFADALTokenCache替代方案，用于实现 TokenCache 。
但是我觉得如果我可以使用会话来代替，那么使用SQL DB太繁琐了。

Vittorio Bertocci's article The New Token Cache in ADAL v2, describes FileCache (for a desktop application) and database EFADALTokenCache alternatives for implementing TokenCache. However I feel that using SQL DB is too heavy if I can use session instead.

任何人都可以提出使用会话的缺点吗？

Could anyone give any cons to use session?

推荐答案

在会话本身中没有反指示，前提是您的方案允许（例如，在没有用户的情况下您不需要访问权限）主动登录），然后正确保护它。但是，这些示例中的类仅用于演示通用缓存组件的功能，并且并未针对用于生产的原样进行强化：您需要添加适当的错误处理，检测和所有软件质量功能您通常会申请自己的生产软件。

There's no counter indication in using the session in itself, provided that your scenario allows for it (e.g. you don't require access when there's no user actively logged in) and you properly secure it. However the class in those samples is meant to only demonstrate the functionality of a generic cache component, and has not been hardened for use in production as-is: you'll need to add proper error handling, instrumentation, and all the software quality features you normally apply for your own production software.

这篇关于是否可以从Azure样本Azure Active Directory OpenId Connect使用NaiveSessionCache的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！