I am trying to implement custom authentication with uses my org's Oauth and gets a token which I would like to pass to my Salt Master of Master. I would want that token to be available in my custom auth module (for the purpose of validating it through my org's APIs). Any idea how can I achieve it.
I have followed below documentation already:
Salt RestCherryPY
Related
In the Symfony Lexik JWT Authentication bundle, It is explained how to authenticate users using a table in the database.
In my case, My users aren't in the database but are in another application that I can access via API calls.
Also, to retrieve the users from this API, all I have to do is send a token associated with every user and get his information.
This token is well handled and is unique for each user.
How can I change the way LexikJWTAuthenticationBundle authenticate users using this API instead of the database.
And after this authentication, I want the JWT token to contain all the user information so I won't have to call this API each time a request is made to my application.
I made this diagram to explain my situation:
I tried from my side building a custom ApiUserProvider and an ApiUserAuthenticator but I am struggling to get this working.
Any help?
Here's described how to manually create JWTs for users: https://github.com/lexik/LexikJWTAuthenticationBundle/blob/2.x/Resources/doc/7-manual-token-creation.md you should be able to use that in your endpoint which authenticates the user, and return your own JWT.
I am implementing Google Sign in in my VueJS App and I have a few questions before starting:
How to create a user when a user clicks on Google sign in button?
Do I have to create a custom route just for that?
Do I have to generate a random password because it is mandatory?
When a user is already registered and clicks on Google Sign in.
Do I have to pass Google Token from Vue JS to Symfony, then with google API, verify if token is valid and generate a token from my symfony application?
If you have some good documentation, I'll take it.
To get this started, it's actually a relatively complicated functionality to implement. This is because you'll have to use custom (maybe multiple if one can both login with Google account or register to your own website) guard authenticators. Moreover, you will need to use an OAuth bundle like KnpUOAuth2ClientBundle or HWIOAuthBundle.
The answer to your questions:
You have to create a custom route for that but you do not need to generate a random password, you can just make password nullable and add checks that it is null only for users logged in through Google (if it's not possible for you then just add something random as password). Additionally, I would propose to add a field provider to your User entity if you are providing both google and your own authentication. You should set this to 'google' or 'website respectively.
The user authentication process is being handled by Google and you are getting an access token as response that contains user's information like name, email etc, so you do not really have to worry about validating passwords etc.
This article helps you get started with KnpUOAuth2ClientBundle.
I search for a solution to authtificate using the access token,
The customer sends a link via email https://www.mywebsite.com/?token=ijn8pC5q2bwftM7dMcjkhkdhgkfdjgfdgg type). when the customer click on the link, the applciation should get automatically the token and then redirect the user his personal page,
Any idea please
You can implement this using an custom authentication guard. This well described in the documentation of symfony. In the example they use an http header field, but you can easily use a query parameter to do the same thing.
As Daniel commented, be aware of token invalidation to ensure a secure application.
I have the ability to login via Facebook and Google on my website. This is done using OAuth2.
I use the same redirect URL whether the user is returning from facebook or google, and pass through the provider name in the state field. Is this the recommended way to track the provider? Otherwise I do not know who to validate the token with if I do not know which provider the token comes from.
Are there other preferred methods for accomplishing this?
The state parameter should be an opaque value that cannot be guessed by an attacker since it is not protected from modifications. If you need to track state, you should refer to it by using the state parameter but that parameter itself should be randomized and/or encrypted. Storing the provider identifier in plaintext in the state parameter is not safe. Users could modify the state parameter themselves or attackers could craft an authorization request with a state value that they choose.
The way to track the provider is by storing it in the backend session state and generate a reference to that session/state that you pass in the state parameter. To prevent cross-site request forgery you should also keep some encrypted/randomized cookie that binds the state to the browser. This is described in more detail: https://www.rfc-editor.org/rfc/rfc6749#section-10.12
Addendum:
One of the problems with using OAuth 2.0 + provider specific extensions for login is exactly this: you cannot establish the provider and user identity in a way that works for all providers in a uniform and generic way. In your case you'll already have to know the provider before you can perform a sensible interaction with it. Enter OpenID Connect: it is a extension profile of OAuth 2.0 that gives you login semantics in a standardized way. It would give you a verifiable JSON object (JWT) with standardized values that tell you who the provider is (iss) and who the user is (sub).
Google signin already has migrated already to OpenID Connect, as has Microsoft and others like Salesforce, hopefully Facebook will follow.
I'm working on a Drupal 6 module to provide OAuth-based user authentication and registration. I'm already using the OAuth module to authenticate as described on http://oauth.net/core/1.0a/#anchor9. The next step is to create the user account using information provided after authentication using an custom API of the Service Provider.
According to http://drupal.org/node/497612#comment-3047302, I should not use user_external_login_register() but see the OpenID module for how to properly login an external user.
After studying the OpenID module, here is what I plan to do:
Try to load an existing user for a authname build from the custom API result using user_external_load().
If a user exists, use user_external_login() to log the user in.
If not, pretend the registration form has been submitted (like openid_authentication() does) to create a new user account. And redirect to a pre-filled form if any additional information is needed in order for the user to register.
Is this the right way to do it ? Is there another module worth looking at for how to this properly in addition to OpenID ?
You could have a look at the former Drupal module. That module did two entirely different things (hooray for the architecture :)).
* It puplished information to a central "who runs Drupal" directory. (and offered a page to show such a directory yourself!)
* It allowed login with credentials from other Drupal-sites.
The latter is what you are looking for. Note that the module was discontinued, not because the method for logging in was done wrong, but because the DrupalID mechanism itself is flawed. It has been replaced with openID and oauth.
http://drupalcode.org/viewvc/drupal/drupal/modules/drupal/drupal.module?hideattic=0&view=markup
The hooks and methods you would be looking for (in that order) are:
drupal_form_alter -- Adds validate-callback to the login forms.
drupal_form_user_login_alter -- Adds information about alternative login on login form.
drupal_distributed_validate -- Validation callback: calls drupal_auth to see if the user is valid. If so, calls user_external_login_register
drupal_auth -- Helper for validation callback: determines if the credentials are valid.
All other functions are either helper functions for these, or provide that directory-feature, or allow remote sites to authenticate against our database. Neither of which you will be using.