Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Wednesday, November 19, 2014 10:33:42 AM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/19/2014 09:33 AM, Stian Thorgersen wrote: > ----- Original Message ----- >> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: >> keycloak-user(a)lists.jboss.org Sent: Tuesday, November 18, 2014 >> 4:36:11 PM Subject: Re: [keycloak-user] Recommendations for >> protecting REST service with bearer token and basic auth > > To obtain an access token, I'd still need to talk with the Auth > server and then, based on the response (ie, synchronously), send a > request with a bearer token to the service. This is not viable when > the client sends several (thousands of) requests to the service. > >> Why does the shell script have to talk to the auth server for >> every request? It should cache the token, not the users >> credentials. I have the strong feeling that I'm missing something very fundamental here, so, I'd be very glad if you could correct me if I'm wrong. I got more time thinking about this, and you are right, caching the tokens is pretty much the only solution that could make this work. But still, it's not very optimal. As I see it, if I have one "business" script, I need two extra scripts. First script: - - User runs the bash script for the first time - - Script generates an URL for the user to open in a browser - - User copies the code from the Keycloak server into the local file system - - Script exchanges this code for a refresh token and stores the refresh token in the local system. Second script: - - Runs every N minutes, where N < "the expiration in minutes of the tokens", updating the refresh and access tokens, and writing it somewhere in the local file system. Third script (my business): - - Reads the token from the local file system and calls the backend. The third script might still fail, if it tries to read the token while it's being written by the second script, but this is manageable. Now, how to handle a multi-host scenario? The user would hopefully not need to execute "first-script" at each host. For that, some sort of token-propagation among the hosts would need to exist. In other words, during peak time, when I spawn more worker hosts, the new hosts would only need to execute scripts 2 and 3. What I'm proposing is something like this: - - User access the "my account" page - - Copies a token/code/secret/key into somewhere in the system - - Bash script reads it and uses it for each backend request, knowing that it will fail only when the user actively revokes this key from his account. Thus, no need for the first script or second script, and no need for any token propagation. I can just spawn new hosts at any time, as the key could be stored in its kickstart file. > > That without mentioning the difficulties in parsing tokens via a > shell script. > >> Why does the shell script have to parse the token? Does it not >> just pass it on to the rest services it invokes. > My bad, not "parsing tokens" but "parsing JSON" (when getting the access token from a refresh token request). - - Juca.