I am new to using doorkeeper gem.I am using this gem to provide authentication to my rails app for API's. For every request we need access token to process that request. Is there any method or feature by which I can block that particular access token and prevent all the request from that token.
Please suggest and thanks in advance. :)
I think that a good approach would be to keep a blacklist with the access tokens that you want to ban, then you have to create a controller action that acts as a middleware before reaching doorkeeper and respond 401 errors in case it is a banned access token
Related
Can I run custom middleware after authentication but before ClaimsTransformation.cs?
ClaimsTransformation uses a token to make an external API call to get some information on the logged in user. I want to pass the OpenId connect token instead, and thus, need that token before the API call is made.
What do you mean with the OpenId connect token instead? id-token or access-token?
The id-token is never allowed to supposed to be passed to any API, it is only meant for the client who initially received it and is typically only used to create the local user session.
One idea is to add a custom middleware between the Authentication and Authorization middleware to manipulate the user.
I'm trying to figure out how to use Auth0 with an Angular/Rails application.
I've set up Auth0 with an Angular-only application and it worked fine. I can see the Auth0 docs for Rails and as far as I can tell it makes sense.
What I don't understand is how to connect the front-end authentication with Rails, since I'm not finding documentation on this anywhere.
Okay, I've figured it out. If I use Auth0 to authenticate on the Angular side and then make an HTTP request to my Rails server, that HTTP request will have an Authorization header with a value like this:
Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2JlbmZyYW5rbGlubGFicy5hdXRoMC5jb20vIiwic3ViIjoiYXV0aDB8NTgzMDZmOTFjMDg4MTRlMDEwMTVmNDM0IiwiYXVkIjoiajNKdHpjYnNpTUkyR0JkRnZGb3FFTjM4cUtTVmI2Q0UiLCJleHAiOjE0Nzk4OTc3OTYsImlhdCI6MTQ3OTg2MTc5Nn0.2cGLY_e7jY0WL-ue4NeT39W4pdxJVSeOT5ZGd_xNmJk
The part after "Bearer", the part starting with "eyJ0", is a JSON Web Token. Henceforth I'll refer to the JSON Web Token simply as the "token".
When Rails receives the HTTP request, it can grab and then decode the token. In my case I'm using Knock.
Knock expects my User model to define a from_token_payload method. Here's what mine looks like:
class User < ApplicationRecord
def self.from_token_payload(payload)
User.find_by(auth0_id_string: payload['sub'])
end
end
My user table has an auth0_id_string column. If I manually create a user whose auth0_id_string matches what I find under sub in the decoded Auth0 token, then my from_token_payload method will find that user and Knock will give me a thumbs up for that token. If no user is found, thumbs down.
So it goes like this, roughly:
Angular asks Auth0 to authenticate a user
Auth0 sends back a JSON Web Token
Angular sends that JSON Web Token to Rails
Rails decodes that token
Rails tries to find a user that matches the data in that token
Rails sends back either a 200 or 401 depending on whether a matching user was found
There are some pieces missing but that's the gist of it. I'll probably end up writing a tutorial on Angular + Rails + Auth0 authentication since, as far as I've been able to tell, none currently exists.
Based on the information you provided I'm assuming that you want to have an application that has the front-end implemented in Angular and uses a Rails based API to provides the services required to the Angular front-end.
In this scenario you can model this as a single (client) application from the Auth0 side of things and do one of the following:
Use the ID token resulting from the authentication for two purposes:
to provide information about the currently authenticated user to the Angular application so that it can meet any applicable user interface requirements
as a way to authenticate calls made by the Angular application to the Rails API, that is, the Rails API uses a token-based authentication system that accepts the ID tokens issued by Auth0.
Expose an endpoint on the Rails API that can be used by Angular to exchange the ID token received upon user authentication by any other credentials that can then be later used to access the API.
The first option is the easiest to implement, but you'll have to include the ID token in every request. The second one increases complexity on your side, but it may allow you more flexibility.
If this does not address all your concerns, can you please update the question with more details about the exact scenario you're trying to accomplish.
A final note, if your intentions are to provide an API that can be later consumed by a different range of applications then the most correct way to secure it would be by using a token-based system where the tokens would be issued by an authorization server compliant with OAuth2.
Having your own OAuth2 authorization server is significantly complex to maintain so Auth0 is in the process of enabling this as an additional service that can already be used in preview mode for accounts in the US region. This would basically allow to obtain as part of the authentication process an ID token used by the client application to know the currently authenticated user and also an access token that would allow to make call into the specified API.
I am using a custom authorization server using Spring. When hitting my protected resource on the client, I am successfully redirected to the auth server. I log in and get the OAuth approval page. Once I authorize the scopes, I am redirected back to my client app with a URL such as:
http://myapp.com/login?code=UjG0wC&state=POez9N
I get that this is the authorization code and it can be exchanged for a token. However, I am having trouble finding examples of how to do this. Do I need to write code to now go and request the token from the auth server, or is there a configuration piece that I am missing? Would it be better to focus on switching to the implicit grant type?
I was missing an AuthorizationServerConfigurerAdapter, which needed to include allowFormAuthenticationForClients()
I'm writing a REST API server(using Rails), and here is a question about session management.
I think for a REST API server, we don't need to save the log in state(or session) for each user. So I just add an authentication token for each user. If they log in, this server will return this token to them, and if log out, destroy it.
And I'm wondering if it's necessary to authenticate this token destroy action? There might be a malicious user who iterate all possible tokens(maybe!) and wrap them in a DELETE request to my server...
Thanks a lot!
One of the aspects of restful web services is statelessness as described in the Wikipedia article.
The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client.
The server should not contain any information about sessions, that means, that the authentication information must be contained in each request and no login or logout methods are needed.
Best practice would be providing a resource (like some OAuth2 implementations), that returns a token with a special scope and an expiration time. At the creating process, the token should be stored in the database of the backend. After the token expires, the information must be deleted from the database and the client has to obtain a new copy of the token.
UPDATE:
#Ekkehard, that's exactly what I meant with my comment. Instead of using ‚stateful' http sessions with a session id, cookies and a session timeout, the token should be provided by an additional resource.
[...] no client context being stored on the server between requests.
If the client wants to access special services of the backend, it had to send a POST request to the token resource (where the backend stores the new token with a special expiration time in the database).
In the POST request, the client could also provide an additional query parameter scope, to create a token, that only allows you to access special parts of your backend (Google for example provides many different APIs like Google Drive, Google Mail, etc. and if the client is a mail application only access to Google Mail is necessary. It’s an additional security feature.).
The response returns the token and the client had to add this token in the header of each request to other resources.
Each request from any client contains all the information necessary to service the request, and session state is held in the client.
The tokens will be verified from the backend based on the information stored in the database.
Token resources could also provide a DELETE http method, to allow the user to delete existing tokens before the end of the expiration time. After the expiration timeout, the tokens will be automatically deleted from the database of the backend.
You can use authentication token for API. Concept is simple if your username and password matched you just create a token and send to user.
You need to set a expiration time for this token.
After expiration time or when API request for destroy you just delete this token.
Token must be send with each request.
In this approach you don't need any session.
RESTful applications must be stateless and the security tokens need to be sent within each request using the header Authorization. Such security tokens are gotten from an authorization server using credentials or using OAuth2 authentication flow (see this link for more details http://www.bubblecode.net/en/2013/03/10/understanding-oauth2/). Such tokens have expiration dates or can be invalidated from this server.
This link could also you give more hints about the way to use tokens within RESTful applications:
Implementing authentication with tokens for RESTful applications: https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
Hope it helps you,
Thierry
If someone knows your token then they can use it to authenticate as you. In other words, by sending the token in to delete, you are authenticating yourself. No additional credentials beyond the token should be needed in a DELETE action.
There are simply too many possible tokens to iterate over for this to be a plausible attack. The attack you are worrying about is not unique to DELETE. If a user could iterate over all tokens then they would be able to impersonate any user for any action.
Simple answer is: YES, you need to authenticate this token destroy action
Here is three things:
If username and password matches user get a token. You need to set a expiration time for this token.
User must have to send token in each request. So, no session in server side is necessary.
If user want to logout, destroy the token from client side, and reset token in server side. And also authenticate this token destroy action
Note: destroy the token after expiration time.
Another Note: Devise gem reset the remember_token, when we logout from web UI.
We are working on an iPhone app that's driven by API in rails. How would login functionality be implemented in Rails? We don't want to use cookies as it's not really 'web' so I am wondering how login is implemented in an API.
Thanks
You can use Token Based Authentication. Rails have authenticate_or_request_with_http_token method which handles the authorization for token. Tokens help in authorization as they can be expired and recreated at any point. You can have a :before_filter to check for the authentication