actualNoteContentPart: This document describes the technical details of the security systems used to protect the Amplenote API. These systems cover interactions between the client applications and the API, but do not include security measures taken in the client applications to protect against various client-specific risks.
   
  # Account Access
  To access your notes in a client application, you must prove that you are who you say you are (authentication), grant the client application access to your account (authorization), and receive an encryption key from the server that will allow the client application to decrypt your note data.
  
  ## Authentication
  To determine which user is authorizing a client application, and verify that you are that user, the API serves a login flow on https://login.amplenote.com
  	User passwords are hashed with [BCrypt](https://en.wikipedia.org/wiki/Bcrypt)  using a [cost parameter of 10](https://gist.github.com/epixoip/63c2ad11baf7bbd57544)  
  	All cookies involved are Secure, HttpOnly, and restricted to login.amplenote.com
  	Headers are set for security-related browser features, including [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) , [HSTS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) , and [X-Frame-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)  
  
  ## Authorization
  Each Amplenote client uses the [OAuth2](https://oauth.net/2/)  authorization code flow to obtain an access token from the API. 
  	Access tokens expire 2 hours after they are issued
  	Access tokens are issued with refresh tokens that can be used to obtain a new access token
  	The authorization code flow supports the nonce parameter described by [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)  
  	The authorization code flow supports [PKCE](https://www.oauth.com/oauth2-servers/pkce/)  
  
  ## Encryption Key Delivery
  The user's Standard Key is delivered to the client upon successful completion of the authorization code flow.
  	The user's Standard Key and Vault Key Salt are included in the id_token payload described by [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)  
  	The id_token is a JWT signed with the server's private key, which can be verified with the [public key]()  
  
   
  # Note Encryption
  Note content is encrypted and decrypted in client applications using AES-256-CBC with a Note Key. The Note Key is encrypted using one of the user's account-wide encryption keys: either their Standard Key or their Vault Key. The user's Standard Key is encrypted at rest with AES-256-GCM - [using a key that the database server does not have access to]()  - and a randomly generated Initialization Vector, while the user's Vault Key is never transmitted to the Amplenote servers. Note Keys remain encrypted in transit, only getting decrypted once they reach the client application.
processedNoteContent: ---
  title: Amplenote Security Design
  tags: 
  ---
  This document describes the technical details of the security systems used to protect the Amplenote API. These systems cover interactions between the client applications and the API, but do not include security measures taken in the client applications to protect against various client-specific risks. 
  Account Access
  To access your notes in a client application, you must prove that you are who you say you are (authentication), grant the client application access to your account (authorization), and receive an encryption key from the server that will allow the client application to decrypt your note data. 
  Authentication
  To determine which user is authorizing a client application, and verify that you are that user, the API serves a login flow on [https://login.amplenote.com](https://login.amplenote.com)`
  
  User passwords are hashed with [BCrypt](https://en.wikipedia.org)`
    using a [cost parameter of 10](https://gist.github.com)`
  
  All cookies involved are Secure, HttpOnly, and restricted to login.amplenote.com
  Headers are set for security-related browser features, including [CSP](https://developer.mozilla.org)`
   , [HSTS](https://developer.mozilla.org)`
   , and [X-Frame-Options](https://developer.mozilla.org)`
  
  Authorization
  Each Amplenote client uses the [OAuth2](https://oauth.net)`
    authorization code flow to obtain an access token from the API.
  Access tokens expire 2 hours after they are issued
  Access tokens are issued with refresh tokens that can be used to obtain a new access token
  The authorization code flow supports the nonce parameter described by [OpenID Connect](https://openid.net)`
  
  The authorization code flow supports [PKCE](https://www.oauth.com)`
  
  Encryption Key Delivery
  The user's Standard Key is delivered to the client upon successful completion of the authorization code flow.
  The user's Standard Key and Vault Key Salt are included in the id_token payload described by [OpenID Connect](https://openid.net)`
  
  The id_token is a JWT signed with the server's private key, which can be verified with the [public key]()
  
  Note Encryption
  Note content is encrypted and decrypted in client applications using AES-256-CBC with a Note Key. The Note Key is encrypted using one of the user's account-wide encryption keys: either their Standard Key or their Vault Key. The user's Standard Key is encrypted at rest with AES-256-GCM - [using a key that the database server does not have access to]()
    - and a randomly generated Initialization Vector, while the user's Vault Key is never transmitted to the Amplenote servers. Note Keys remain encrypted in transit, only getting decrypted once they reach the client application.
noteTitle: Amplenote Security Design