IndieWeb Concepts ================= This document explains the IndieWeb concepts and protocols implemented by django-indieweb. What is IndieWeb? ----------------- The IndieWeb is a people-focused alternative to the "corporate web". It's a community of independent website owners who want to own their data and stay connected. Key principles include: - **Own your data** - Your content lives on your domain - **Syndicate elsewhere** - Cross-post to social networks - **Interoperability** - Standards-based protocols for communication IndieAuth Protocol ------------------ IndieAuth is a federated login protocol that uses your own domain name as your identity. It's built on top of OAuth 2.0 but simplified for the IndieWeb use case. How IndieAuth Works ~~~~~~~~~~~~~~~~~~~ .. mermaid:: graph TD A[User owns domain.com] --> B[User wants to sign in to app.com] B --> C[App redirects to user's auth endpoint] C --> D[User authenticates on their own site] D --> E[Auth endpoint redirects back with code] E --> F[App exchanges code for verification] F --> G[User is logged in as domain.com] Key Components ~~~~~~~~~~~~~~ 1. **Identity (me)** - Your domain name (e.g., ``https://example.com``) 2. **Client ID** - The application requesting authentication 3. **Authorization Endpoint** - Where users approve access 4. **Token Endpoint** - Where codes are exchanged for tokens 5. **Redirect URI** - Where to return after authorization IndieAuth vs OAuth ~~~~~~~~~~~~~~~~~~ While similar to OAuth, IndieAuth has key differences: - Your identity is your domain, not an account on a service - No client registration required - Simpler flow focused on authentication and authorization - Designed for individual website owners Micropub Protocol ----------------- Micropub is a protocol for creating posts on your website using third-party clients. Core Concepts ~~~~~~~~~~~~~ .. mermaid:: graph LR A[Micropub Client] --> B[Sends POST request] B --> C[With access token] C --> D[To Micropub endpoint] D --> E[Creates content] E --> F[Returns 201 Created] Post Types ~~~~~~~~~~ Micropub supports various post types through the ``h`` parameter: - ``h-entry`` - Standard blog posts, notes, articles - ``h-event`` - Events with start/end times - ``h-card`` - Profile/contact information Common Properties ~~~~~~~~~~~~~~~~~ - ``content`` - The main post content - ``name`` - Post title - ``category`` - Tags/categories - ``in-reply-to`` - URL being replied to - ``location`` - Geographic coordinates - ``photo`` - Image URLs Implementation Architecture --------------------------- django-indieweb implements these protocols with three main components: .. mermaid:: classDiagram class Auth { +key: str +owner: User +client_id: str +redirect_uri: str +scope: str +me: str +created: datetime } class Token { +key: str +owner: User +client_id: str +me: str +scope: str +created: datetime } class AuthView { +get() : authorization code +post() : verify code } class TokenView { +post() : access token } class MicropubView { +get() : configuration +post() : create content } Auth --> AuthView : creates AuthView --> TokenView : provides code TokenView --> Token : creates Token --> MicropubView : authenticates Data Flow ~~~~~~~~~ 1. **Authorization Phase** - User visits AuthView with client details - Django authenticates user (standard login) - Auth object created with temporary code - User redirected back to client with code 2. **Token Exchange** - Client POSTs code to TokenView - Code validated (exists, not expired, matches parameters) - Token object created with access key - Access token returned to client 3. **Content Creation** - Client sends POST to MicropubView with token - Token validated (exists, active user, correct scope) - Content would be created (not implemented) - Success response returned Security Model -------------- Authorization Codes ~~~~~~~~~~~~~~~~~~~ - Single use - deleted after exchange - Time limited - 60 seconds by default - Bound to specific client_id and redirect_uri - Random 32-character strings Access Tokens ~~~~~~~~~~~~~ - Long-lived (no built-in expiration) - Bound to user, client, and scope - Can be revoked by deleting Token object - Should be transmitted over HTTPS only Scopes ~~~~~~ Scopes limit what actions a token can perform: - ``create`` - Create new posts - ``update`` - Modify existing posts (not implemented) - ``delete`` - Remove posts (not implemented) - ``read`` - Access private posts (not implemented) Best Practices -------------- For Service Providers ~~~~~~~~~~~~~~~~~~~~~ 1. Always use HTTPS in production 2. Validate all parameters strictly 3. Implement rate limiting 4. Log authorization attempts 5. Consider token expiration For Users ~~~~~~~~~ 1. Only authorize apps you trust 2. Use unique passwords for your domain 3. Review authorized apps regularly 4. Revoke unused tokens Limitations ----------- Current implementation limitations: 1. **Micropub is not functional** - Only returns success without creating content 2. **No token expiration** - Tokens are valid indefinitely 3. **No token revocation UI** - Must delete via Django admin 4. **No scope enforcement** - Only checks for "post" in scope 5. **No media endpoint** - Can't upload images 6. **No update/delete** - Only create operations Future Enhancements ------------------- Potential improvements for full IndieWeb support: 1. **Functional Micropub** - Actually create content 2. **Media Endpoint** - Handle file uploads 3. **Micropub Extensions** - Update, delete, undelete 4. **Token Management** - UI for viewing/revoking tokens 5. **WebSub** - Real-time updates 6. **Webmention** - Receive mentions from other sites Resources --------- - `IndieWeb.org `_ - Main IndieWeb community site - `IndieAuth Spec `_ - Protocol specification - `Micropub Spec `_ - Micropub specification - `IndieAuth.com `_ - Reference implementation