Table of Contents |
---|
Apiary | |||||||
| mithril/api/apps | ||||||
Scope | app:authorize |
Purpose
Modification existing WS: Create approvals - add handling logic (validation) for same type of tokens
Request parameters
- token
- client_id
- redirect_uri
- scope
Logic WS
- Validate $.token
- Get token by $.token
- Extract token_type, user_id
- Get user by user_id
- Validate user id & user status
- Validate user `is_blocked` flag
- if is_blocked = TRUE
- return 4xx - "User blocked" (!!! TBD)
Get active 2FA item for non-blocked user by $.user_id
Code Block language sql SELECT * FROM authentication_factors AS 2FA INNER JOIN user AS U ON 2FA.user_id = U.id WHERE U.id = $.user_id AND U.is_active = TRUE AND U.is_blocked = FALSE AND 2FA.is_active = TRUE
- If not exist 2FA active item for user
- If token_type = access_token - go to standard process create Approvals & return changed token (existing logic)
- At any token_type - return 4xx error "" !!! TBD
- If exist active 2FA
- if token_type = access_token - go to standard process create Approvals & return changed token (existing logic)
- If token_type = 2fa_access_token - return 401 error
- If not exist 2FA active item for user
Response
An 2FA feature implementation WS authorize-an-approval suppose token with right scopes list at token in HEADER (example: -H 'authorization: Bearer b3IxNTBBZXR6VWg3MHdYNEFoL3ZUUT09' ).
It means the following (see details in specs for WS: Create Token)
token_type | scopes at token.details |
---|---|
authorization_code | "scope": "app:authorize" |
2fa_access_token | "scope": "" |