Post/simple part1 simple api lockdown #14
Conversation
|
|
||
| Something like: | ||
|
|
||
| Requesting APP (using the wonderful Faraday): |
There was a problem hiding this comment.
Maybe link to Faraday? (in a new window)
|
Yeah I'd definitely update the title, maybe add the word "encryption" in it, cause it's sexy How to encrypt a rails api... etc.. etc... |
| author: paul_franzen | ||
| summary: Ever needed a simple way to lock down an API? | ||
| image: http://res.cloudinary.com/wework/image/upload/s--Al86WVSb--/c_fill,fl_progressive,g_face:center,h_1000,q_jpegmini:1,w_1600/v1427921778/engineering/5-ways-to-create-bulletproof-software-bear.jpg | ||
| categories: rails, api, security, engineering |
There was a problem hiding this comment.
we should probably limit these to shorten the url no? We've been going with just "engineering" now, which is redundant, tbh this category stuff needs to be revisited
|
@mattjstar adding Encryption into the title will unleash a momentus Reddit shit torrent in the this posts direction if it is not 100% accurate and bulletproof.... tread lightly. |
|
ah, k |
| > | ||
| > This belief can sometimes mean uncomfortable travels in which trust outweighs mistrust and you are willing to take on risk in the interest of greater success for both yourself and your community. | ||
| > | ||
| > Ok. Now that's out of the way. What follows is a system/explanation, undoubtedly flawed, but one which We hope will help some folks to understand some security concepts a little better and maybe help them in there travels. |
| end | ||
| ``` | ||
|
|
||
| Now we are accessing this user based on an easily revoke-able token in the client app. |
There was a problem hiding this comment.
But now you have to look up the User by their token, which was the whole thing we wanted to avoid in the first place, right?
You could dispense with the encrypted_user_uuid stuff and just use a token if that's your style.
There was a problem hiding this comment.
this would function as a "double layer" which would allow our base auth service to continue to feed out to any and all apps it serves, while the individual apps could run their own "extra" tokeny system
There was a problem hiding this comment.
Interesting. I think there are some tradeoffs there in letting individual apps run additional authentication schemes. Could be a good discussion, up to you. (Like, what if I can authenticate to half the apps but not the other half? That would be a weird situation. Note that authentication != authorization.)
No description provided.