I have my web application. Now i want to integrate salesforce into my web app so that i can push data from my app to any salesforce org after the authentication(OAuth).
I found 2 ways:
1. Connected Apps
2. via wsdl generation file and use
I created a connected app from my developer account and i authenticated using consumer key, cusumer secret key(from my connected app) and username of user and secret token of the user account.
I tried with another free trail account, It's validating and fetching the details and post data also working.
My question is, shall i deploy my connected app into app exchange, then only i caan use REST APIs ?
generating wsdl and coding around is the better option than the above ?
Is there a option, only one time authentication enough for any number of sessions and use the REST APIs?
Please suggest me a best way to proceed.
You're mixing up a couple of independent issues here.
If you're going to authenticate via OAuth, you must have a Connected App.
A SOAP API login() call requires you to store a username and password, which is undesirable.
There is no way to "permanently" authenticate, i.e., to get a session id that never expires. Your app must always be ready to get a new access token via the OAuth refresh token it obtains and stores (via, for example, the Web Server OAuth flow), or to reauthenticate via JWT flow.
Connected Apps are global metadata in most cases. You don't need to deploy a Connected App into a target org in order to authenticate using its Client Id and Secret into that org. The only exception I'm aware of is if you want to use the JWT flow with a certificate and preauthorized Profiles and Permission Sets.
Based on what you've shared, I don't see any reason for the AppExchange to be involved.
Related
I am making an Android application with a Django based backend.
The Django server has a REST API to serve user data which I want to protect. I only want my users to log in via Google (or FB which I'm going to implement in the future).
I am using django-rest-framework-social-auth to implement the authorization in the backend.
So the flow as I understand is like this:
The client (my android application), does the whole Google OAuth2.0
flow and obtains the access token
The the client then wants to
convert the Google access token with one with which it can access my
backend server API endpoints. To do this it calls the convert-token
API endpoint implemented in django-rest-framework-social-auth
Now that it has the API access token, it can include that in the header of all further API calls and receive the private data.
Now my concern is, the django-rest-framework-social-auth convert-token endpoint also needs the client-id and client-secret generated by django-oauth for the application. So I will have to store the client-secret somewhere in my mobile app, which entirely defeats the purpose of authenticating whether the request came from the app or not, because someone can decompile the apk and get the app and make token exchange requests on my app's behalf.
Is there any way around this? Is there a "standard" way to implement this which I don't know?
How can one use Firebase Authentication to allow users to authenticate with a Google account via the C++ SDK (using it in Cocos2d-x).
I’m confused as to whether I would need to build a special Google auth GUI or if the SDK requires/contains a standardized GUI (or, in the case of Cocos2d-x, a Scene) that should be used.
Either way, I am unsure how to do it. Does anyone know how to proceed? The SDK example code shows how to authenticate via Email/Password but not via a Google Account.
Ok, so this is complicated, but not because of Firebase.
Basically, if you want to use a Federated Logon, such as Facebook, Google, Twitter, then you will need to use their UI SDK built for whichever platform you are using. When you successfully login with one of these services, you will construct a Credential with the token that is returned from one of these services.
After you login with this credential, the Firebase Auth service will associate any account data with this federated logon. If you were previously using an anonymous login, then the account should be upgraded. If you have already logged in with another credential (email, phone number, alternative federeated logon) then you will need to do some logic to check if you need to merge or switch.
Firebase Auth can outlive the Federated Token. For example, the Facebook Login token expires or is revoked, your Firebase Auth backend might remain signed in. Vice versa your Facebook token might not expire, but your Firebase Auth might have been signed out. You will need to manage these states.
Here's an example. We want to use Facebook Login as our federated logon provider. We link the Facebook Login SDK for our platform as described in the Facebook Developer docs.
When we want to ask for Facebook login credentials, we use the FBSDKLoginManager .loginwithReadPermissions() to launch the login flow. This typically consists of launching either the Facebook App to confirm permissions for your app or the website (make sure you implement deep links properly as described in the Facebook documentation).
Eventually, the login will succeed or fail.
If it succeeds, Facebook will hand you a token which you can grab from [FBSDKAccessToken currentAccessToken].tokenString. This is what you would send to firebase::auth::FacebookAuthProvider::GetCredential
All of this is ASync and done on separate threads. You should use a concurrent queue to funnel these events to your main thread.
It is possible to use your own server and signup form, in which case you would build your own UI in game and then make secure server calls to your backend. There's a flow for getting a text message to validate a user, not something I would do for a game.
I have a Django application that currently stores user credentials and performs authorization and authentication. I am in the process of breaking off the front-end into an Angular SPA and converting the backend to a REST API. My Django API will live as an Azure API app protected by Azure API Gateway. I would like to remove the authentication piece from Django and allow users to sign in using OpenID Connect through either Google or Microsoft Account. What I would like to happen is this:
When a user visits the site, assuming they have never registered with my app, they will have the option to sign in with their Google account or Microsoft Account. If the user decides to sign in using their Google or Microsoft account, (this is where I'm confused and why i'm posting here ... ) I think what happens is the API Gateway performs the authentication, generates a JSON Web Token (JWT), and sends that token back to the Django API. Django receives the JWT, decrypts it, and checks to see if there is a user account matching the email address in the JWT. If there is not a user account, Django will add a user to the user accounts table (not storing a password). If there is a user matching that email address, then Django allows the user in.
All that said, I guess my question(s) are:
Should I do the authentication at the API Management Gateway or should I do it at the Azure Web API?
Can I use Django's built-in authentication system to do what I want or is that not needed?
Am I over-complicating all of this? Is there an easier way to do this? All this seems like a lot of work.
Is OpenID Connect what I should be using (instead of Oauth2)? I have no experience with either.
Azure API Management does not actually provide any kind of JWT issuing mechanism, so you'll have to implement that yourself. The end points for doing that may or may not be exposed via API management.
What possibly gets you confused is the fact that the APIm Portal supports various indentity providers, like Twitter or Google, to sign up for the API. But these are not your application users, these are for the API Portal Users.
What you can do with the APIm Gateway is to validate subsequent calls to your backend API that the supplied JWT token is valid (using the <validate-jwt> policy).
I want to be able to authenticate users of an angular.js application using oauth, but I do not want to store any tokens on the frontend because I have seen that it can be fairly complicated to do so securely. Is there a way to pass some sort of credentials of a user to my django web application, where is can authenticate the user with some oauth provider and save that information in a session? To make it simple, here is the process I want
User is logged into some oauth provider, i.e. stackexchange
They click a "login with stackexchange" button on the front end angular app
Their login credentials are sent over to the django application through a restful api
The django app which receives these credentials attempts to get a token using rauth
If the server receives a token, the user is logged in and their information is saved in a session, otherwise they are given an error
Is this sort of process supported by OAuth2 providers?
Step 3 is incorrect: that authentication process is handled entirely off-site, on the OAuth provider's infrastructure, e.g. StackExchange.
This kind of flow is certainly possible. I would check out the Facebook example, which uses Flask, but provides a similar framework for how you might go about this in Django.
I'm working on an iPhone app that uses xAuth to login to Twitter. The app also communicates with my own web service. Rather than maintain a user model inside the web service, I'd like to just allow anyone who's already authenticated via Twitter to make requests.
The high-level use case is this: the user logs into and interacts with Twitter through the app. They can also interact with my web service through the app. The web service itself never interacts with Twitter. Instead of maintaining a separate authentication system on my side, I'd like the server to say "OK, if Twitter says you're #joshfrench then you can have access."
I'm not sure how I should validate requests on the server side, though. How would I pass some proof of authentication from the mobile client to my web service? Can I send along the existing Twitter token and verify it from the server? Or somehow sign the request with my Twitter app's credentials? Is this even a valid use of OAuth?
If you store your twitter app key and secret on both he iphone app and your server, and then somehow transmit the user's oauth token (also called "access token") key/secret from the iphone app to the server, then you can do the same type of api calls from the server.
consumer = OAuth::Consumer.new(app_key, app_secret, …)
access_token = OAuth::AccessToken.new(consumer, user_key, user_secret)
response = access_token.get('/stuff.xml')
So, is it Okay to transmit that info from the app to the server? If you do it securely, and it's within the user's expectation for how the app behaves, then it's a perfectly fine use of oauth.
It's possible that it's not allowed by Twitter's terms of service -- I could imagine there being something that says you can't transfer a user's access secret across the network, or some such thing. (total wild speculation, I don't think it's particularly likely that that's the case)