|
| 1 | +# HTTPie Auth Store |
| 2 | + |
| 3 | +> [!NOTE] |
| 4 | +> |
| 5 | +> The plugin was renamed from `httpie-credential-store` to `httpie-auth-store` |
| 6 | +> primarily due to backward incompatible changes and because the new name |
| 7 | +> better reflects its nature. |
| 8 | +
|
| 9 | +HTTPie Auth Store is an [HTTPie] authentication plugin that automatically |
| 10 | +selects the appropriate authentication type and payload from a file containing |
| 11 | +authentication bindings, then uses them for the current request. No more |
| 12 | +memorizing or searching for tokens, usernames, or passwords — simply add them |
| 13 | +to the authentication store, and the plugin handles the rest. This plugin also |
| 14 | +supports various secret storage options, such as system keychains and password |
| 15 | +managers (see supported [Secret providers]). |
| 16 | + |
| 17 | +Eager to get started? Just start with installing! |
| 18 | + |
| 19 | +```sh |
| 20 | +httpie cli plugins install httpie-auth-store |
| 21 | +``` |
| 22 | + |
| 23 | +or via `pip` in the same python environment where HTTPie is installed: |
| 24 | + |
| 25 | +```sh |
| 26 | +python3 -m pip install httpie-auth-store |
| 27 | +``` |
| 28 | + |
| 29 | + |
| 30 | +## Table of Content |
| 31 | + |
| 32 | +* [Usage](#usage) |
| 33 | +* [Authentication types](#authentication-types) |
| 34 | + * [basic](#basic) |
| 35 | + * [digest](#digest) |
| 36 | + * [bearer](#bearer) |
| 37 | + * [header](#header) |
| 38 | + * [composite](#composite) |
| 39 | + * [hmac](#hmac) |
| 40 | +* [Secret providers](#secret-providers) |
| 41 | + * [sh](#sh) |
| 42 | + * [system](#system) |
| 43 | + * [password-store](#password-store) |
| 44 | +* [FAQ](#faq) |
| 45 | + |
| 46 | + |
| 47 | +## Usage |
| 48 | + |
| 49 | +> [!IMPORTANT] |
| 50 | +> |
| 51 | +> Do not forget to pass `-A store` or `--auth-type store` to HTTPie in order to |
| 52 | +> activate the plugin. |
| 53 | +
|
| 54 | +Once installed, the plugin looks for `auth_store.json` located in the HTTPie |
| 55 | +configuration directory. On macOS and Linux, it tries the following locations: |
| 56 | +`$HTTPIE_CONFIG_DIR/auth_store.json`, `$HOME/.httpie/auth_store.json` and |
| 57 | +`$XDG_CONFIG_HOME/httpie/auth_store.json`; on Windows — |
| 58 | +`%HTTPIE_CONFIG_DIR%\auth_store.json` and `%APPDATA%\httpie\auth_store.json` |
| 59 | + |
| 60 | +> [!NOTE] |
| 61 | +> |
| 62 | +> The authentication store can be automatically created with few examples |
| 63 | +> inside on first plugin activation, e.g. `http -A store https://pie.dev`. |
| 64 | +
|
| 65 | +The authentication store is a JSON file that contains two sections: `bindings` |
| 66 | +and `secrets`: |
| 67 | + |
| 68 | +```json |
| 69 | +{ |
| 70 | + "bindings": [ |
| 71 | + { |
| 72 | + "auth_type": "bearer", |
| 73 | + "auth": "$GITHUB_TOKEN", |
| 74 | + "resources": ["https://api.github.com/"] |
| 75 | + }, |
| 76 | + { |
| 77 | + "id": "bots", |
| 78 | + "auth_type": "bearer", |
| 79 | + "auth": "ZWFzdGVyIGVnZwo", |
| 80 | + "resources": ["https://api.github.com/"] |
| 81 | + }, |
| 82 | + ], |
| 83 | + "secrets": { |
| 84 | + "GITHUB_TOKEN": { |
| 85 | + "provider": "system", |
| 86 | + "service": "github.com", |
| 87 | + "username": "ikalnytskyi" |
| 88 | + } |
| 89 | + } |
| 90 | +} |
| 91 | +``` |
| 92 | + |
| 93 | +Each _binding_ is a JSON object that contains the following keys: |
| 94 | + |
| 95 | +* `id` (*str*, *optional*) is an authentication binding ID that can be used to |
| 96 | + overcome ambiguity when two or more bindings are matched. |
| 97 | + |
| 98 | +* `auth_type` (*str*, *required*) is an authentication type supported by HTTPie, |
| 99 | + either natively or via third-party plugins. See [Authentication types] for |
| 100 | + details. |
| 101 | + |
| 102 | +* `auth` (*str*, *optional*) is an authentication payload for the given |
| 103 | + authentication type. Required for certain authentication types, optional for |
| 104 | + others. Tokens started with `$` are replaced with secrets referred by those |
| 105 | + tokens. The `$` sign must be escaped (`$$`) to remain untouched. |
| 106 | + |
| 107 | +* `resources` (*List\[str\]*, *required*) is an array of URLs to activate this |
| 108 | + binding for. Must contain both scheme and hostname. |
| 109 | + |
| 110 | +Each _secret_ is a KV-pair, where key is a secret name, and value is either a |
| 111 | +secret itself or a JSON object that specified how a secret must be retrieved |
| 112 | +from secure storage. The JSON object must contain the `provider` key. Presence |
| 113 | +of other keys are provider dependent (see [Secret providers] section below). |
| 114 | + |
| 115 | +Once the authenticate store is set up, just pass `-A store` to HTTPie to |
| 116 | +activate the plugin and perform some magic for you. |
| 117 | + |
| 118 | +```sh |
| 119 | +http -A store https://api.github.com |
| 120 | +``` |
| 121 | + |
| 122 | +If there are two or more authentication bingind in the store that match the |
| 123 | +same resource, you can select appropriate binding by providing a binding ID by |
| 124 | +passing `-a` or `--auth` to HTTPie. This might come handy when you have |
| 125 | +multiple accounts on the same web resource. |
| 126 | + |
| 127 | +```sh |
| 128 | +http -A store -a bots https://api.github.com |
| 129 | +``` |
| 130 | + |
| 131 | + |
| 132 | +## Authentication types |
| 133 | + |
| 134 | +HTTPie Auth Store supports both built-in and third-party HTTPie authentication |
| 135 | +types as well as provides few authentication types on its own. |
| 136 | + |
| 137 | +> [!TIP] |
| 138 | +> |
| 139 | +> It's advised to store your secrets in password managers instead of storing |
| 140 | +> them directly in the authentication store file. |
| 141 | +
|
| 142 | +### basic |
| 143 | + |
| 144 | +The 'Basic' HTTP authentication type as defined in RFC 7617. Transmits |
| 145 | +credentials as username/password pairs, encoded using Base64. |
| 146 | + |
| 147 | +```json |
| 148 | +{ |
| 149 | + "auth_type": "basic", |
| 150 | + "auth": "ihor:p@ss" |
| 151 | +} |
| 152 | +``` |
| 153 | + |
| 154 | +where |
| 155 | + |
| 156 | +* `auth` is a `:`-delimited username/password pair |
| 157 | + |
| 158 | +### digest |
| 159 | + |
| 160 | +The 'Digest' HTTP authentication type as defined in RFC 2617. It applies a hash |
| 161 | +function to the username and password before sending them over the network. |
| 162 | + |
| 163 | + |
| 164 | +```json |
| 165 | +{ |
| 166 | + "auth_type": "digest", |
| 167 | + "auth": "ihor:p@ss" |
| 168 | +} |
| 169 | +``` |
| 170 | + |
| 171 | +where |
| 172 | + |
| 173 | +* `auth` is a `:`-delimited username/password pair |
| 174 | + |
| 175 | +### bearer |
| 176 | + |
| 177 | +The 'Bearer' HTTP authentication type transmits token in the `Authorization` |
| 178 | +HTTP header. |
| 179 | + |
| 180 | +```json |
| 181 | +{ |
| 182 | + "auth_type": "bearer", |
| 183 | + "auth": "t0ken" |
| 184 | +} |
| 185 | +``` |
| 186 | + |
| 187 | +where |
| 188 | + |
| 189 | +* `auth` is a bearer token to authenticate with |
| 190 | + |
| 191 | +### header |
| 192 | + |
| 193 | +The 'Header' authentication type is not exactly an authentication scheme. It's |
| 194 | +rather a way to set a free-formed HTTP header that may or may not contain any |
| 195 | +secret material. |
| 196 | + |
| 197 | +```json |
| 198 | +{ |
| 199 | + "auth_type": "header", |
| 200 | + "auth": "X-Secret:s3cret" |
| 201 | +} |
| 202 | +``` |
| 203 | + |
| 204 | +where |
| 205 | + |
| 206 | +* `auth` is a `:`-delimited HTTP header name/value pair |
| 207 | + |
| 208 | +The 'Header' authentication type can be used to bypass any kind of limitations |
| 209 | +imposed by built-in or third-party authentication types. For instance, you can |
| 210 | +pass a bearer token with non-default authentication scheme, say `JWT`, without |
| 211 | +breaking a sweat. |
| 212 | + |
| 213 | +```json |
| 214 | +{ |
| 215 | + "auth_type": "header", |
| 216 | + "auth": "Authorization:JWT t0ken" |
| 217 | +} |
| 218 | +``` |
| 219 | + |
| 220 | +### composite |
| 221 | + |
| 222 | +The 'Composite' authentication type is a not an authentication type either. |
| 223 | +It's a way to use multiple authentication types simultaneously. It might come |
| 224 | +handy when in addition to `basic` or `bearer` authentication, you have to |
| 225 | +supply an extra secret via custom HTTP header. |
| 226 | + |
| 227 | +```json |
| 228 | +{ |
| 229 | + "auth_type": "composite", |
| 230 | + "auth": [ |
| 231 | + { |
| 232 | + "auth_type": "bearer", |
| 233 | + "auth": "t0ken" |
| 234 | + }, |
| 235 | + { |
| 236 | + "auth_type": "header", |
| 237 | + "auth": "X-Secret:s3cret" |
| 238 | + } |
| 239 | + ] |
| 240 | +} |
| 241 | +``` |
| 242 | + |
| 243 | +where |
| 244 | + |
| 245 | +* `auth` is a list of authentication entries, as supported by HTTPie |
| 246 | + |
| 247 | +### hmac |
| 248 | + |
| 249 | +The 'HMAC' authentication type is not built-in and requires the `httpie-hmac` |
| 250 | +plugin to be installed first. Its only purpose here is to serve as an example |
| 251 | +of how to use a third-party authentication type in the authentication store. |
| 252 | + |
| 253 | +```json |
| 254 | +{ |
| 255 | + "auth_type": "hmac", |
| 256 | + "auth": "secret:czNjcjN0Cg==" |
| 257 | +} |
| 258 | +``` |
| 259 | + |
| 260 | +where |
| 261 | + |
| 262 | +* `auth` is a HMAC specific authentication payload |
| 263 | + |
| 264 | + |
| 265 | +## Secret providers |
| 266 | + |
| 267 | +The plugin supports some secret providers that can be used to retrieve tokens, |
| 268 | +passwords and other secret materials from various secured storages. |
| 269 | + |
| 270 | +### sh |
| 271 | + |
| 272 | +The 'Sh' secret provider retrieves a secret from the standard output of the |
| 273 | +shell script. This is a universal approach that can be used to retrieve secrets |
| 274 | +from unsupported password managers using their command line interfaces. |
| 275 | + |
| 276 | +```json |
| 277 | +{ |
| 278 | + "provider": "sh", |
| 279 | + "script": "cat ~/path/to/secret | tr -d '\n'" |
| 280 | +} |
| 281 | +``` |
| 282 | + |
| 283 | +where |
| 284 | + |
| 285 | +* `script` is a shell script to execute |
| 286 | + |
| 287 | +### system |
| 288 | + |
| 289 | +The 'System' secret provider, as the name suggests, retrieves a secret from |
| 290 | +your system keychain. It may be KWallet, GNOME Keyring, macOS Keychain or even |
| 291 | +Windows Credential Locker. |
| 292 | + |
| 293 | +```json |
| 294 | +{ |
| 295 | + "provider": "system", |
| 296 | + "service": "github", |
| 297 | + "username": "ikalnytskyi" |
| 298 | +} |
| 299 | +``` |
| 300 | + |
| 301 | +where |
| 302 | + |
| 303 | +* `service` is a service to retrieve a secret from |
| 304 | +* `username` is a username to retrieve a secret from |
| 305 | + |
| 306 | +### password-store |
| 307 | + |
| 308 | +The 'Password Store' secret provider invokes the `pass` executable on your |
| 309 | +system, and retrieves the secret from the first line of referred record. |
| 310 | + |
| 311 | +```json |
| 312 | +{ |
| 313 | + "provider": "password-store", |
| 314 | + "name": "github.com/ikalnytskyi" |
| 315 | +} |
| 316 | +``` |
| 317 | + |
| 318 | +where |
| 319 | + |
| 320 | +* `name` is a password-store entry name to retrieve a secret from |
| 321 | + |
| 322 | +## FAQ |
| 323 | + |
| 324 | +* **Q**: How to get know what authentication is used for the given request? |
| 325 | + |
| 326 | + **A**: You can run HTTPie with `--offline` argument to print the request |
| 327 | + header along with injected authentication credentials. |
| 328 | + |
| 329 | + |
| 330 | +[HTTPie]: https://httpie.org/ |
| 331 | +[Authentication types]: #authentication-types |
| 332 | +[Secret providers]: #secret-providers |
| 333 | +[password-store]: https://www.passwordstore.org/ |
0 commit comments