Mobile authentication using QR in web application

Question

I have doubts about what the correct schema should be for the next technical solution. I need to authenticate a user in a mobile application by reading a QR code, the user being previously authenticated in a web application.

The use case consists in that the user uses a web application located in an intranet, but needs to be able to upload images from a mobile device that will be connected to the internet. The mobile application will consume a public API exposed on the internet through a API Gateway. The API Gateway will connect to the backend to upload the images. As a requirement, when the user needs to use the mobile device to capture and upload images, they should not authenticate again, since they have an open session in the web application, and simply use a QR code to authenticate the device. Logically the QR will not use the user's credentials.

My idea is to make use of Oauth 2.0 with the following flow to authenticate mobile device:

1. The web application requests API Gateway to generate an authorization token and it responds with a UUID.
2. The web application will display the authorization token using a QR received from the API Gateway.
3. The mobile device will read the QR, and request an access token to the API Gateway with the authorization token.
4. The API Gateway validates the authorization token and generates the access token that is returned to the mobile device.
5. The mobile device makes calls to the public API (API Gateway) using the access token.

My question is whether it is the correct scheme, or there is another standard solution.

Thanks!!

Answer 1

Your scheme will work BUT it's not reaching its fullest security potential considering the fact that you can transfer a new generated authorization token from an already authorized device directly to another one(via QR code read by camera); this fact would make step 3 and 4 an unnecessary vulnerability(it's also a redundancy,there already is a token!, why get another one?);

The following alternative along with good cryptography can make the later authorized device connection almost impossible to intrude.the idea is that by adding a symmetric encryption layer before sending the data in step 5 and using a key which is exchanged over another medium(the already authorized device and server) the encrypted data can never be exposed;

step 3 replacement: read the authorization token;

step 4 replacement: check the secure hash derivation of the authorization token(instead of the token itself) with the server to see if its valid;

token0=read_auth_token_from_camera()
public_token=hash_function(token0) //the useless exposed token
if(check_token_with_server_for_authenticity(public_token)==true)
    continue_to_step_5() //it's authorized
else
    handle_the_scenario()

step 5 replacement: encrypt your request and authorization token with another hash derivation of the authorization token then make calls to the server API;

token2=another_hash_function(token0)
request="i am top secret data"
encryption_key=token0
encrypted_request=encryption_function( token2 + request , encryption_key)
send_to_server( public_token+encrypted_request)
//notice that token2 is unknown to the intruder because its encrypted,but it is known to the server; hence the authenticity of each request can be checked by the server;

how it is more secure: in this alternative way the actual authorization token is never really exchanged between the server and the new client; So if an intruder could hypothetically break the SSl/TLS layer and capture the public token, the intruder won't be able to send any requests on your behalf or modify the data in requests;