Accessing the current client app using Doorkeeper - ruby-on-rails-3

I'm using Doorkeeper to manage client applications on a Rails-based API I'm building. I have a controller action in which I'd like to check some information about the client app that submitted the request which the action is handling.
Does Doorkeeper provide a helper or other easy way to access (in a controller) the Doorkeeper::Application that made the request being processed? I'm envisioning an analogue to Devise's 'current_user' method.
If no such helper exists, how can I get this information?

And now I've figured it out.
Doorkeeper provides doorkeeper_token, which can be accessed in the controller. This is a Doorkeeper::AccessToken object, which references the app the token belongs to (as doorkeeper_token.application). This is referenced (in the example code) here.

Related

Look up the user with bearer token with Openiddict Core

I am currently using Openiddict, Identity and Entity Framework to manage my users and assign Bearer tokens to users to protect my API.
My infrastructure is currently using ASP.NET Core Web API in the back end and a separate React application in the front end. The React application makes HTTP calls to my API to retrieve it's data. There is no server side HTML rendering at all in the back end.
Everything works as I need it to for the most part. I can register users and retrieve tokens from the API. These tokens are included in my HTTP call in the Authorization header. My AuthorizationController uses this: https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Controllers/AuthorizationController.cs with a few minor tweaks. My Startup.cs also uses almost exactly this https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Startup.cs
In some instances, I need to make API calls to the endpoints that are specific to the user. For instance, if I need to know if a user has voted on a comment or not. Instead of passing along the users ID in a query string to get the user details, I would like to use the Bearer token I received that they use to make the API call for that endpoint. I am not sure how to do this though.
In some research I have done it looks like some samples use ASP.NET Core MVC as opposed to the API to retrieve the user with the User variable as seen here https://github.com/openiddict/openiddict-samples/blob/dev/samples/PasswordFlow/AuthorizationServer/Controllers/ResourceController.cs#L20-L31 however this seems not to apply to my infrastructure.
My question is how do I look up a user based on the Bearer token passed to the API to look up a users details from my database? I am assuming that all of the tokens passed out by the API are assigned to that specific user, right? If that's the case it should be easy to look them up based on the Bearer token.
The question is: How with Openiddict can you look up a user based on the token that was assigned to them for API calls? I need to get the user details before anything else can be done with the application first. Is there something baked internally or do I have to write my own support for this?
When you create an AuthenticationTicket in your authorization controller (which is later used by OpenIddict to generate an access token), you have to add a sub claim that corresponds to the subject/entity represented by the access token.
Assuming you use the user identifier as the sub claim, you can easily extract it from your API endpoints using User.FindFirst(OpenIdConnectConstants.Claims.Subject)?.Value and use it to make your DB lookup.

Yii2 Rest API user authentication

I am implementing Rest API in yii2. I want to authenticate the user using access token. I have referred various SO answers as follows
Rest api bearer authentication
Rest api bearer auth
Yii2 Rest api authentication
But I m not clear, which authentication method I should use and how I will get user identity.
I have created findIdentityByAccessToken() method in my user identity class as suggested in Yii2 Rest guide .
Below is the behaviour implemented in my controller
public function behaviors() {
$behaviors = parent::behaviors();
$behaviors['authenticator'] = [
'class' => HttpBasicAuth::className(),
'except' => ['login','forgot-password']
];
return $behaviors;
}
now, how I will get the user identity inside my controller action? As far as i know, access token will be set from the web service inside request header.
Note : I am using Yii2 advanced app
please help me.
Simple answer there's more than one possibility to implement this behavior.
Both HttpBearerAuth and HttpBasicAuth can use the findIdentityByAccessToken() methode when configured correctly. the behavior you should use depends on the way you want users to authenticate themselves.
if you read the documentation of HttpBasisAuth HttpBasicAuth you'll see
The default implementation of HttpBasicAuth uses the loginByAccessToken() method of the user application component and only passes the user name. This implementation is used for authenticating API clients.
loginByAccesToken will invoke the findIdentityByAccesToken methode
You can manipulate this behavior by defining a closure in the auth attribute see auth attribute.
HttpBeareAuth almost does the same. it also implements the loginByAccessToken
So what make the two different from each other? simple the location where the get the data from. where HttpBasicAuth expects that client has set the basic header example header('Authorization: Basic '. base64_encode("user:password")); (PHP has build in support for this see: http://php.net/manual/en/features.http-auth.php)
the HttpBearerAuth expects that the header is defined as the following header('Authorization: Bearer '. $token);
So the solution you should use depends on the way you want users/clients to authenticate themselves. you could also use the QueryParamAuth which gives the users the possibility to authenticate themselves whit a GET param see queryparamauth
And if you want to use a custom header let's say X-API-Token create your own custom class that implements the AuthMethod interface see AuthMethod
Hope this helps

Ember-Simple-Auth 3.1 using Ember-Simple-Auth-Devise.js Callback

I'm using Ember-Simple-Auth on an Ember-CLI project, and I'm also using the provided ember-simple-auth-devise authenticator that comes with 3.1. I'm able to login and logout successful, but I can't figure out where's the best place to put the callback (or when the promise resolves) upon successfully logging in. I want to be able to use the data returned by my API on my app after logging in. Any suggestions and advice would be highly appreciated! If requested, I can also provide code samples (although I figured it wasn't necessary since what I have implemented thus far is nothing custom).
Thanks!
When the session is authenticated successfully, the sessionAuthenticationSucceeded action is triggered (see http://ember-simple-auth.simplabs.com/ember-simple-auth-api-docs.html#Ember-SimpleAuth-ApplicationRouteMixin-sessionAuthenticationSucceeded, there are also more actions for other events). So that's a good place to react to the session becoming authenticated.
As the authenticator will set all values the server responds with as properties on the session you could also define additional properties that depend on these - see example here (where the account property depends on the accountId property that's read from the server response): https://github.com/simplabs/ember-simple-auth/blob/master/examples/4-authenticated-account.html#L101

Passing custom information in an Omniauth request

I'm currently implementing an omniauth solution for an app that will initially be in an invite only mode.  I can restrict the UI so that a person cannot see the registration screen from which omniauth could be activated unless they have a valid invitation code.  That being said, if a user knew the url structure, they could try to initiate the omniauth process directly and I'm trying to figure out how to handle that.  I can't lock down the authentication url because an already registered user would need to go through them and they would not have their invitation code after the initial registration.  Ideally I'd like to pass the invitation code along in the omniauth request so that it would come back to the app upon success, but in looking I found this thread which said that is not possible.
http://groups.google.com/group/omniauth/browse_thread/thread/4d99d608...
Is this still true or is it now possible to do what I'm looking for? Is setting the value in the session still the preferred way or is there a better way to handle this when using OmniAuth?
Thanks in advance
Chris
Instead of passing the custom info along with the omniauth request, you can first store the info to somewhere (like session). And in the oauth callback, you check the invitation code of current session, if it's available, register the user.

Custom PrinciplePermission Authentication

Our system uses a custom roles, and authentication system to Authenticate users.
I am now looking into the service side validation/security.
I want implement our custom Authentication, Authorization on the wcf too.
I have done some investigation, it looks like I could use the PrinciplePermission attribute on the contracts to allow/deny access. The default just calls the IsInRole method on the IPrinciple and the IsAuthenticated on the IIdentity.
So I have 2 questions:
How do implement my own custom principle which has additional data/methods?
How do I add addition checks to the PrinciplePermissions? e.g (IsExternal which will check if they are accessing the service from the intranet or internet [have a mechanism to monitor this already])
Thanks
After some experimenting I came up with a custom written solution:
I based my solution in Kyle McClellan's Authorisation Sample. I adapted the attributes to look at a custom class to retrieve the user.
To get around the async problem I loaded the user and his relevant data in the App.xaml prior to instantiating the MainPage, I then make use of a global singleton, which I called SecurityContext, to access user data.
The SecurityContext is an in-memory store of the user data that can be accessed clientside.