 6d5172d18a
			
		
	
	6d5172d18a
	
	
	
		
			
			* first pass
* dependency shenanigans
* move blueprints
* few broken links
* change config the throw errors
* internal file edits
* fighting links
* remove sidebarDev
* fix subdomain
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix relative URL
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix mismatched package versions
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix api reference build
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* test tweak
* links hell
* more links hell
* links hell2
* yep last of the links
* last broken link fixed
* re-add cves
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add devdocs redirects
* add dir
* tweak netlify.toml
* move latest 2 CVES into dir
* fix links to moved cves
* typoed title fix
* fix link
* remove banner
* remove committed api docs
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* integrations: remove version dropdown
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Update Makefile
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* change doc links in web as well
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix some more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* ci: require ci-web.build for merging
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Revert "ci: require ci-web.build for merging"
This reverts commit b99a4842a9.
* remove sluf for Application
* put slug back in
* minor fix to trigger deploy
* Spelled out Documentation in menu bar
* remove image redirects...
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* remove explicit index.md
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* remove mdx first
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* then remove .md
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add missing prefix
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
		
	
		
			
				
	
	
		
			52 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			52 lines
		
	
	
		
			2.2 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| # Device code flow
 | |
| 
 | |
| (Also known as device flow and [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628))
 | |
| 
 | |
| This type of authentication flow is useful for devices with limited input abilities and/or devices without browsers.
 | |
| 
 | |
| ### Requirements
 | |
| 
 | |
| This device flow is only possible if the active brand has a device code flow setup. This device code flow is run _after_ the user logs in, and before the user authenticates.
 | |
| 
 | |
| authentik doesn't ship with a default flow for this usecase, so it is recommended to create a new flow for this usecase with the designation of _Stage configuration_
 | |
| 
 | |
| ### Device-side
 | |
| 
 | |
| The flow is initiated by sending a POST request to the device authorization endpoint, `/application/o/device/` with the following contents:
 | |
| 
 | |
| ```
 | |
| POST /application/o/device/ HTTP/1.1
 | |
| Host: authentik.company
 | |
| Content-Type: application/x-www-form-urlencoded
 | |
| 
 | |
| client_id=application_client_id&
 | |
| scopes=openid email my-other-scope
 | |
| ```
 | |
| 
 | |
| The response contains the following fields:
 | |
| 
 | |
| -   `device_code`: Device code, which is the code kept on the device
 | |
| -   `verification_uri`: The URL to be shown to the enduser to input the code
 | |
| -   `verification_uri_complete`: The same URL as above except the code will be prefilled
 | |
| -   `user_code`: The raw code for the enduser to input
 | |
| -   `expires_in`: The total seconds after which this token will expire
 | |
| -   `interval`: The interval in seconds for how often the device should check the token status
 | |
| 
 | |
| ---
 | |
| 
 | |
| With this response, the device can start checking the status of the token by sending requests to the token endpoint like this:
 | |
| 
 | |
| ```
 | |
| POST /application/o/token/ HTTP/1.1
 | |
| Host: authentik.company
 | |
| Content-Type: application/x-www-form-urlencoded
 | |
| 
 | |
| grant_type=urn:ietf:params:oauth:grant-type:device_code&
 | |
| client_id=application_client_id&
 | |
| device_code=device_code_from_above
 | |
| ```
 | |
| 
 | |
| If the user has not opened the link above yet, or has not finished the authentication and authorization yet, the response will contain an `error` element set to `authorization_pending`. The device should re-send the request in the interval set above.
 | |
| 
 | |
| If the user _has_ finished the authentication and authorization, the response will be similar to any other generic OAuth2 Token request, containing `access_token` and `id_token`.
 |