Skip to main content

​
Overview

The ApplicationUser model represents users in the RealtimeChat application. It extends ASP.NET Core Identity’s IdentityUser class, providing built-in authentication, authorization, and user management capabilities while adding custom properties for chat functionality.

​
Model Purpose

ApplicationUser serves as the central user identity model, enabling:
  • User authentication and authorization
  • Profile information management
  • Message authorship tracking
  • Chat room participation management
  • Integration with ASP.NET Core Identity features

​
Properties

​
Identity Properties

​
Id
string
required
Unique identifier for the user. Inherited from IdentityUser. Used throughout the system to reference users.
​
UserName
string
required
Unique username for login and display. Inherited from IdentityUser.
​
Email
string
required
User’s email address for authentication and notifications. Inherited from IdentityUser.

​
Custom Properties

​
FirstName
string
User’s first name. Optional field for personalization.
​
LastName
string
User’s last name. Optional field for personalization.
​
Messages
array
Collection of all messages sent by this user across all chat rooms.
​
ChannelParticipants
array
Collection of chat room participation records for this user.

​
ASP.NET Identity Properties

In addition to the custom properties above, ApplicationUser inherits many properties from IdentityUser, including:
  • PasswordHash: Hashed user password
  • SecurityStamp: Random value that changes when credentials change
  • EmailConfirmed: Whether the email address has been confirmed
  • PhoneNumber: Optional phone number
  • PhoneNumberConfirmed: Whether phone number has been confirmed
  • TwoFactorEnabled: Whether two-factor authentication is enabled
  • LockoutEnd: Date/time when lockout ends (if applicable)
  • LockoutEnabled: Whether lockout is enabled for this user
  • AccessFailedCount: Number of failed login attempts
These inherited properties are managed by ASP.NET Core Identity and provide comprehensive user account security features.

​
Relationships

​
Messages

One-to-many relationship with messages. Each user can send multiple messages across different chat rooms. The relationship is established through the UserId foreign key in the MessageEntity table.

​
Chat Room Participations

Many-to-many relationship with chat rooms through the ChatRoomParticipantEntity join table. This enables:
  • Users to join multiple chat rooms
  • Chat rooms to have multiple participants
  • Tracking of user membership for authorization

​
GraphQL Type Representation

While the full ApplicationUser model contains sensitive identity information, the GraphQL API exposes a filtered view: 
type User {
  id: String!
  userName: String!
  firstName: String
  lastName: String
}
Email addresses and other sensitive identity properties are not exposed through the GraphQL API for privacy and security reasons.

​
Example JSON Representation

{
  "id": "user-abc-123-def-456",
  "userName": "johndoe",
  "email": "john.doe@example.com",
  "firstName": "John",
  "lastName": "Doe"
}

​
Complete User with Relationships

{
  "id": "user-abc-123-def-456",
  "userName": "johndoe",
  "email": "john.doe@example.com",
  "firstName": "John",
  "lastName": "Doe",
  "messages": [
    {
      "id": 101,
      "sentAt": "2026-03-05T09:15:30Z",
      "chatRoomId": 5,
      "content": {
        "text": "Good morning everyone!"
      }
    }
  ],
  "channelParticipants": [
    {
      "id": 1,
      "chatRoomId": 5,
      "userId": "user-abc-123-def-456"
    },
    {
      "id": 2,
      "chatRoomId": 7,
      "userId": "user-abc-123-def-456"
    }
  ]
}

​
Database Schema

public class ApplicationUser : IdentityUser
{
    public string? FirstName { get; set; }
    public string? LastName { get; set; }
    
    public ICollection<MessageEntity> Messages { get; set; } = null!;
    public ICollection<ChatRoomParticipantEntity> ChannelParticipants { get; set; } = null!;
}
The model inherits from IdentityUser, which provides all standard ASP.NET Core Identity properties and integrates with the Identity framework’s user management, authentication, and authorization systems.

​
Privacy and Security Considerations

​
Data Protection

  • Password Security: Passwords are hashed using ASP.NET Core Identity’s secure hashing algorithms
  • Email Privacy: Email addresses should only be visible to the user themselves and administrators
  • Personal Information: FirstName and LastName are optional and should be treated as PII

​
API Exposure

When exposing user data through GraphQL or REST APIs:
  • Never return password hashes or security stamps
  • Limit email address visibility based on privacy settings
  • Consider user preferences for name display
  • Implement proper authorization checks for user data access

​
Authorization Best Practices

query GetCurrentUser {
  me {
    id
    userName
    firstName
    lastName
    email  # Only accessible to the authenticated user
  }
}

query GetUserProfile($userId: String!) {
  user(id: $userId) {
    id
    userName
    firstName
    lastName
    # Email intentionally not exposed
  }
}

​
Integration with Authentication

ApplicationUser integrates seamlessly with ASP.NET Core Identity for:
  • Registration: New user account creation
  • Login: Username/email and password authentication
  • Token-based Auth: JWT tokens for API access
  • Password Reset: Secure password recovery flows
  • Email Confirmation: Email verification workflows
  • Two-Factor Authentication: Optional 2FA support
  • Account Lockout: Protection against brute force attacks

​
Best Practices

  • Username Uniqueness: Enforce unique usernames at both database and application levels
  • Email Verification: Require email confirmation for new accounts
  • Display Names: Use FirstName and LastName for personalized UI when available
  • Privacy: Default to privacy-preserving settings for user data exposure
  • Authorization: Always verify user identity before allowing profile modifications
  • Audit Logging: Log sensitive operations like password changes and email updates

Build docs developers (and LLMs) love

Get started for freeTalk to us