Re: [aerogear-dev] Android OAuth2 PR
On 2014-05-05, Summers Pittman wrote:
On Mon 05 May 2014 03:15:45 PM EDT, Bruno Oliveira wrote:
>
>Hi Summers, I totally understand the need to store. Just don't know how
>the application will behave when token is required. Why?
I'll try to answer with an example and feel free to interrupt me if I
misunderstood you.
User Authorizes and all the appropriate tokens are stored in the
AuthzService
User schedules a pipe to download something in the future.
In the future Pipe.read fires, but the token is expired.
The Pipe's onFailure method is called with a (hopefully) useful exception.
The user can refresh the auth token and retry, fire up a notification to say
"User stuff went sidesways" or just crash (a personal favorite of mine).
Only to be clear, no problem on storing access tokens or nor renewing
tokens. What I don't get is if you guys want to use encryption for some
reason, how it would look like to call for example some API.
I see the whole proposal into this way (I'm taking shortcuts here to go
straight to the point)
1. Get the access token
2. Reconstruct the private key based on some password provided
3. Encrypt access token
Now I want to send a request to my server
4. Require the password to reconstruct my private key
5. Decrypt it from the local storage or whatever
6. Send the HTTP request (I will just be lazy and copy
from google)
```
GET /youtube/v3/channels?part=id&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer 1/6BMfW9j53gdGImsixUH6kU5RsR4zwI9lUVX-tqf8JXQ&
```
Next login, if the token is the same, repeat the steps 4 to 6. What I'm
trying to say here is: password-based encryption will hurt your
usability, we must think about temporary keys instead of request the
password everytime I need to send a request to the server.
Yep, I know these tokens will be renewed. But you need the previous one
to request a new token.
--
abstractj