Im trying to put the pieces together for Parse Servers Twitter Authentication but Im not sure how it works, The documentation here has the following info https://docs.parseplatform.org/parse-server/guide/#twitter-authdata but theres not so much detailed information about how to actually implement a full twitter auth flow.
I have managed to piece together an expressJS flow but how do I pass sensitive data to cloud functions from the express routes ?
Would really love to see an example of parse/twitter backend flow.
Related
I want to use auth from google firebase, and integrate it with spring boot.
I am not sure that I have good idea how to implement roles/authorities.
I have in mind this scenario:
On success authentication with firebase, frontend send request to secured spring backend endpoint, and data on this endpoint contains which roles should user have, so frontend use this data to set claims for user. Backend use claims to authorize user when accessing endpoints.
Is this okey, or is there faster/better solution?
That sounds like a good approach. Have a look at the Firebase documentation on verifying ID tokens as that'll be your starting point once your backend receives the token from the client.
The only addition I can make at this point is that many of Firebase's own backend services cache recently decoded tokens (with the undecoded token as the key) to allow subsequent requests to more quickly look up the information for that token. While this is not required, it's an easy speed up once you're ready for that.
I'm working on an Absinthe GraphQL API for my app. I'm still learning the procedure(so please go easy on me).
I've a Absinthe/GraphQL MyAppWeb.schema.ex file in which I use for my queries and mutations. My question is how do I use this API for authenticating the user on both Mobile and Web app?
How do set a cookie(httpOnly & secure) in my web app and access/refresh tokens in a single Absinthe API to serve my website and mobile app. Basically what I'm trying to learn is how do I authenticate the user based on specific platform.
If my question sounds bit confusing, I would be happy to provide more information related to my question. I would really be grateful if someone could explain the procedure, I've been very stuck on this for a while.
I would avoid using authentication mechanisms provided by absinthe(if there are any). Depending on what front-end you are using, I would go with JSON API authentication. The flow on server goes the following way:
Create a endpoint for login that will receive a user and password and will return a refresh token.
Create a endpoint for exchanging refresh token for access token.
Use a library like guardian to generate your refresh/access tokens.
Create a phoenix plug for authentication that will check your tokens, guardian has some built-in plugs for this.
Now on device you have to implement:
Ability to save refresh and access token on device.
Have a global handler for injecting access token on authorized requests.
Have a global handler for case when access token is expired. (you usually check if your request returns Unauthorized, then you should request a new access token from the server using your refresh token)
This seems like a crude implementation, however I would advise in implementing your system instead of using a black box library that you have no idea how it works under the hood.
I've seen a lot of posts recommending using Xamarin.Auth for SSO in Xamarin, but having reviewed a tutorial as well as the GitHub Getting Started wiki (in which says it supports "Authorization Code Flow", but seems to require a secret key from the client to get the auth code, which is not what I'm looking for) and searched the web fruitlessly for "Xamarin.Auth implicit flow", and "Xamarin.Auth authorization code flow", it appears to me that Xamarin Auth supports only Implicit flow, which is less secure than an Authorization Code flow for a native app that is connected to a backend web server application as mine is. Am I correct in understanding that Xamarin.Auth can only support an implicit flow (requiring that the access token be sent to the client, and a client_secret can't be retained server-side and sent server-side as part of the retrieval of the access token), and not an authorization code flow (in which the client would receive only an authorization code, which it would then send to the server, which then would retrieve the access token using a client-secret and possibly a PKCE exchange)?
Furthermore, even flows with other libraries I've seen recommended seem to retrieve the access token to the client - AppAuth supports PKCE, which is a security improvement vs no PKCE, but the posts I see showing examples of it here and here and here still all retrieve the access token on the client. Auth0 is also recommended in some posts I've seen (e.g. here), but the example I see for that here also retrieves the access token on the client.
Is there a reason why sites are not doing this? Is there a sample or API documentation anyone can point me to for a library that does support retrieving only an authorization code client-side in a Xamarin application? (and then separately, server-side, using that to retrieve the access token using a client-secret, not necessarily with the same security library since that would not need to be Xamarin code - this server-side part I feel confident is a pretty standard thing - e.g. as outlined for Auth0 here)?
Xamarin.Auth do support Authorization Code Flow. As you find in the tutorial, Xamarin.Auth's OAuth2Authenticator class has a parameters called 'Client Secret', together with other provided parameters, Xamarin.Auth is capable of handling the Authorization Code exchange part and return the access token directly back to you, it looks like this part didn't happen, but actually it did.
Digging into OAuth2Authenticator source code, method VerifyOAuth2FlowResponseType shows Xamarin.Auth provides both Authorization Code Flow and implicit flow. For more detailed information, you may read the code together with The OAuth 2.0 Authorization Framework
And here is an example for Authorization Code Flow from client side.
I have been playing with Thinktecture IdentityServer3 and am keen to use it as the product looks great. However, I don't fully understand how to accomplish my flow which is probably fairly common:
Create Identity Server using Implicit flow
Setup an MVC web site
Setup a separate Web API
So far so good, as demonstrated in the examples on the site. I now wish to call the API using AJAX calls directly but for this i need an access token. It seems like a large overhead to have to route these through the MVC site itself (again, in the examples).
How can I accomplish this flow? Would it essentially blend the MVC and Javascript Client samples or is there a smoother way so the user only has to sign in once? Perhaps send the access token in a hidden field but then how would it renew?
Any help on understanding this would be great.
I've managed to come up with a solution which seems to work, not sure if it's best practice though...
Expose a method on the MVC site at AJAX/AccessToken
Method should be locked down with Authorize attribute to ensure the MVC part of the site is authenticating properly with IdentityServer
Method returns the users Access Token which was generated through the above call via MVC controllers
In JavaScript, simply use this endpoint to get an Access Token and then call the API manually
The call to get the Access Token should be secure as its within the same domain/authentication model as the MVC site itself
I've put up a sample here for anyone interested:
OIDC-Website
Check out the form post client to see the endpoints being called explicitly. You will need to hit the token endpoint to get your access token.
You should be able to use these endpoints in your AJAX calls, store the received claims and tokens in a cookie and take it from there.
Note that to renew the access token, you will also need to store the refresh token. The Implicit flow does not allow for refresh tokens (you'll need to use the Authorization Code Flow or the Hybrid Flow).
I am currently trying to use the Grackle Ruby GEM to integrate with the Twitter API, but I have encountered a little snag.
I am attempting to perform a GET to twitter.com/oauth/request_token, but according to the OAuth spec I need to provide the following values:
oauth_consumer_key
oauth_signature_method
oauth_signature
oauth_timestamp
oauth_nonce
I am a little stumped, as at this point Twitter has only given me a Consumer Key and a Consumer Secret. Am I just going about this the hard way? Because I cannot figure out how to correctly populate those values. No matter what I supply Twitter keeps returning:
Failed to validate oauth signature and
token
It sounds like my problem is just a general misunderstanding on how to properly integrate with Twitter and OAuth in general, and not so much the specifics of Grackle... but perhaps too much information is best in this case :-)
First of all, you should probably be reading the latest OAuth rev, which is 1.0a. There are no differences when obtaining the request token though so you should be fine in that regard.
Apart from that, it looks like a combination of general misunderstanding of the OAuth process and the scope of Grackle:
The process of acquiring the access
token and token secret are outside the
scope of Grackle and will need to be
coded on a per-application # basis.
Grackle comes into play once you've
acquired all of the above pieces of
information (source).
So, I would first look towards a library that can get you an access token before continuing with Grackle. Moomerman's twitter_oauth looks like a good choice: http://github.com/moomerman/twitter_oauth
Hope that helps!
I encountered this same issue, and all the examples for the oauth gem online I could find were out of date. I wrote an explanation with sample code here, but the basic flow is:
Get a Request Token from Twitter and save the details
Send the user to Twitter with that token
Get the user back, use details and response from Twitter to generate an Access Token
Use the Access Token's token and secret with your Consumer token and secret to make API calls.