Blazor (InteractiveServer) + ASP.NET Identity library & GDPR

Question

This question is about what Blazor (IdentityServer) and the ASP.NET Core Identity Library does under the covers with respect to GDPR, CCPA, etc.

First off, if a user is not authenticated by the Identity Library, is Blazor and/or the Identity Library using any tracking cookies or other items that GDPR/CCPA have rules concerning and/or forbidding?

Second, once a user is authenticated, same question. What is it using to authenticate a user back in with no prompts. And if the user wants that deleted, how do I do it? And can I turn that off for a user? Or would turning it off mean Blazor thinks they're not authenticated on each new page?

In short:

1. What do I need to tell users the system is tracking about them?
2. What do I have my app restrict itself to if they decline cookies, etc.?
3. What do I need to delete if they delete their account? (Yes I have to delete records in my database, my question is anything stored somehow by Blazor and/or the Identity Library.)

Answer 1

Disclaimers:

• IANAL. _(Context)
• My answer is based on data from official sources, such as the GDPR's own website, in addition to guidance from authorities such as the French CNIL's GDPR Developers's Guide (the CNIL is France's regulator for data and privacy).
  • I'm intentionally avoiding sources such as websites that independent law-firms, cookie-consent-banner vendors and the like, and marketing companies have set-up, due to their obvious conflicts-of-interest.
• Once again, IANAL; so if you're building a system where a GDPR fine will cost your company more than the cash-value of the amount of time it took me to write this post then you should consult a lawyer.
• I'll use the term "ASP.NET" as shorthand to refer to ASP.NET Core and its constituent sub-systems, such as ASP.NET (Core) MVC, Blazor, SignalR, and so on.
  • Blazor does not have any kind of special integration with ASP.NET (Core) Identity as far as I know.

---

First off, if a user is not authenticated by the Identity Library, is Blazor and/or the Identity Library using any tracking cookies or other items that GDPR/CCPA have rules concerning and/or forbidding?

• Some nuance is needed here:

  • "Cookie" is not a dirty-word.
  • What constitutes "tracking" - and therefore a "tracking cookie" depends on your application. It's inaccurate to brand any and all cookies as a form of "tracking"; but we also need to keep-in-mind that an innocuous and very legitimate cookie, could end up unintentionally facilitating unauthorized tracking.

• But my short answer is that an ASP.NET web-application, using ASP.NET Core Identity, set-up with common or sensible defaults, will not be issuing cookies users, even authenticated users, that would require you to seek consent from your users (i.e.: no cookie consent form is needed).

• Note that ASP.NET will still be issuing "strictly necessary" cookies, these are functional cookies, which are set as first-party-only by default, generally have a short duration, and are encrypted with a key known only to your server instance (so if the cookies were leaked or exposed and if they contained encrypted PII then that PII would be safe).

• If you're curious about those cookies, then the main cases that immediately spring to my mind are:

  • CSRF antiforgery token cookies
  • TempData
  • Use of ASP.NET's in-box Session state system
  • Load-balancer affinity cookies (strictly speaking, this isn't usually ASP.NET doing it, but it can, depending on your application

Second, once a user is authenticated, same question.

• I assume you are not using any kind of federated authentication or third-party IDP such as "Sign-in with Google" or "Login with Facebook". If you are, then that complicates things and is beyond my ability to answer.

  • You can still use SAML/OAuth/OIDC with first-party IDPs (e.g. Keycloak or IdentityServer); but I also cannot say, either way, whether or not IDP-as-a-service platforms (like Entra or Auth0) are in-the-clear. You should contact them directly and find out what steps you need to take in their platform to be GDPR compliant.

• Once a user is authenticated, using a browser-based authX scheme in ASP.NET, then (typically) they'll be issued their authentication-cookies which will typically contain their PII (their "user claims", such as their name, email, phone, profile details, etc): but the entire cookie is encrypted with a private-key that should only known by your web-server(s), so there's no risk of PII disclosure, these cookies are also secure-by-default in modern versions (i.e. no JS access ("HTTP-only"), require TLS/SSL, "first-party", etc).

• I am not aware of ASP.NET (Core) Identity issuing any additional cookies of its own beyond what ASP.NET Core's authentication system issues.

What do I need to tell users the system is tracking about them?

I think you're mistaken about the basis of your question here: with respect to cookies, in my opinion, the system isn't "tracking" the user at all: we aren't trying to follow their movements elsewhere on the web nor trying to fingerprint them so that other people could try to identify them elsewhere. The only thing ASP.NET is doing here is essentially giving the user a virtual membership card into your website, and it's up to the user to choose to present that membership-card to your website to gain access and they can choose to throw that membership-card away at any point they like (by closing the browser-window (in the case of session-lifetime'd cookies or Incognito-mode), or by clearing their cookies (in the case of persisted-cookies).

• The GDPR's website does offer guidance that websites should be transparent and inform users about what each cookie does. In my opinion, that's something you'd put in the Privacy Policy page linked-to from the footer.

• But keep-in-mind that "tracking" and data-collection concerns far more than just ASP.NET (Core) Identity's impact on your system: it concerns each field you have in your registration form, for example - regardless of if those fields interact with ASP.NET (Core) Identity.

What do I have my app restrict itself to if they decline cookies, etc.?

Assuming that we're talking about a stock, common-or-garden vanilla-flavoured plain bagel ASP.NET website using ASP.NET (Core) Identity with no external services, then your question is moot because your website will only be issuing "strictly necessary" cookies that are fundamentally required for the safe and secure operation of your website, so there is nothing for the user to decline consent for.

But, for example, if your customized your ASP.NET website to issue a uniquely identifying and long-life'd cookie to your visitors on the first request (i.e. including unauthenticated visitors) and used that to associate those browsers/sessions with users once they logged-in and/or after they logged-off but still browsing your website, and without any informed consent, even if it was confined to your own website, then that would be a GDPR violation in my opinion. But there are very legitimate reasons for doing something like that (e.g. user-experience monitoring) and there is a way of doing that legally, with explicit consent (e.g. something like a checkbox on the confirm-logout or post-logout page), but because this is murky if you find yourself facing this situation you should speak to your legal team.

Oh, and things get hairier if you're using a third-party analytics service and to what extent these services you're using share/intermingle/anonymize/aggregate the data they're getting from you. So, as a notable example, if you're using Google Analytics at all then you've got a lot more work to do if you want to remain compliant.

What do I need to delete if they delete their account?

I cannot answer this question because this isn't a technical question: it depends on the basis and nature of your organisation's relationship to your website's users and you might even be legally obligated to retain user data instead of being obligated to delete it.

Is anything stored somehow by Blazor and/or the Identity Library.

• Provided you configured ASP.NET (Core) Identity to use your own database (e.g. with Entity Framework Core), then the only information stored is the information that you specifically configured ASP.NET to store, and therefore you only need to delete the subset of that information that your legal team has told you that you need to.

• The above advice, actually... this entire answer post does not apply if you configured ASP.NET (Core) Identity to use external/federated auth/IDP (as I mentioned earlier). Things may also be materially different if you're using things like on-prem Active Directory or LDAP with ASP.NET (Core) Identity.

  • So while ASP.NET (Core) Identity will give you enough rope to hang yourself with, it also comes with sensible defaults, and I'm going to assume that your website's user-registration form doesn't ask your visitors for their sequenced DNA, nonnormative sexual proclivities, and notarized mental health records.

• I will make some suggestions about things to consider w.r.t. deleting data when a user requests it, for example:

  • If you're using a caching layer that's persisted (e.g. Redis).
  • Remember that your DB backups will necessarily contain data that users will have requested deleted. I've never heard of any organisation throwing away their DB backups because they contained data subject to customer deletion requests but they did all have procedures in place to ensure that verboten data would be exised from a live system immediately after any backup restore operation (and yes, I'm aware of the irony of how this means you're required to retain metadata about deleted data in order to comply with data-deletion requests).
  • If a user ever checked the "Remember me on this computer/browser" checkbox on the login page before they requested you delete their data then you're going to need a way to force-delete that cookie should they ever use that computer/browser again in future.
  • Most webservers generate access-logs (text-files with 1 line per incoming HTTP request), these logs typically store the date+time, HTTP request method and path, IP addresses, request+response duration, size and status code; and often the full querystring or even the entire request cookie payload (which they should not be doing...). Most webservers only retain logs for about a week, and often orgs will run these logs through some aggregation and reporting system for technical and operational reasons (e.g. request failure rate, server load, etc). Depending on your application these logs will likely be PII (e.g. due to PII in request paths and IP addresses. Assuming your aggregation process is sufficiently anonymizing and your log rotation isn't longer than necessary I don't expect you'll need to do anything here for a user-data-deletion-request; and as said, you may even be legally obligated to retain some kinds of PII (like IP addresses) for abuse prevention in future.
  • I assume your application also makes error-logs with details of exceptions, stack-traces, and relevant data. Handling this is also very application/context-sensitive. You might have a problem if your devs are just bulk-copying PII-laden error-logs into your issue-tracking system. Most (all?) of the major error-logging systems out there (e.g. Serilog for ASP.NET Core) can be configured to preemptively redact or censor labelled PII fields (e.g. via C# attributes applied to entity properties) or even heuristics.
    • On a related note, SQL Server too now supports data-labelling which may be helpful (or even required) in your org.