Google AppEngine's "guestbook" tutorial is very nice and clean.
It's awesome how easy I can authenticate my users via Google Accounts.
Now, imagine if my application was a GWT application.
I can make two pages: Login.jsp and MyApp.jsp then "protect" MyApp.jsp with a simple if / else condition, just like in the guestbook tutorial.
Then my web app will use things like gwt-rpc to ajax-communicate with my services. But...
how can I make this services secure? Do I have to pass them username/password every time and check every time the authentication? Can you tell me more about it?
And what about if I want to use my own Users, instead of Google Accounts? How can I keep my user logged in? By saving the logged user's sessionId inside the User entity for example?
Thx
If the user is logged in using the Users API, all the Javascript RPC calls they make will also carry the authentication cookies required. You can simply check if the user is authenticated using the regular Users API, as you would for an interactive request.
Related
I'm working on a react app where the pages can be used both by authenticated and anonymous users. The pages show more features for the authenticated users.
If a user previously has signed in and revists the website, I want the user to be automatically authenticated, and am struggling to achieve this.
I'm using redirect methods because I don't believe popup is working well on phones (is that assumption correct?).
I have tried storing the homeAccountId in local storage and use that to get the account used and then calling login in the msal instance. I also set up a addEventCallback and listen for EventType.LOGIN_SUCCESS which I use to set some internal state about the logged in user.
I have tried using MsalAuthenticationTemplate but strangely this doesn't invoke a login. I have also tried to detect if this is a "first run" and then invoking the login, but that doesn't work all the time. Sometime I get a SSO error indicating I should provide a login_hint or sid which is not possible because I use B2C.
If I don't do anything the user can click the login button and if the user has a valid cookie with B2C the user is logged in without providing credentials which is a strange behavior for the user because my website indicate the user is not authenticated (and show no logout button).
So I can't really get this to work and are wondering if somebody has a concept for achieving this?
Please checkout the msal-react samples which all demonstrate the behavior you're looking for. The MsalAuthenticationTemplate would be the recommended way to do this and if you're still having issues getting this to work after reviewing the samples I would recommend opening an issue on our repo with code snippets so we can take a closer look at what's going on.
Also using localStorage, if you're not already, would help to maintain application state between browser sessions. sessionStorage is the default.
As for B2C not asking for credentials; server state is separate from client state. You can be signed in on the server without the application knowing about it. Until your application makes a request to the B2C server your application will show that a user is not signed in. If a session already exists on the server when you make a login request, the server may redirect you back to your application without asking for credentials again.
I am trying a post-call to generate an access token using the client username and password. I would like to know how we can achieve this through Node Js Code.
Generally speaking, access_token are rattached to the OAuth2 authentication framework, which doesn't require the application owner (you) to have access to one of your user email/password. This is a more secure approach that is broadly adopted.
The way OAuth2 works on the Google Calendar API is a 3-parties (or 3-legged) authorization. Let's take the example of a user that browses your website and want to sign-in using its Google Account. The steps to authenticate him are the following:
The user clicks on "Sign-in with Google"
The application owner (you) performs a request to Google saying that a user wants to connect (that's the OAuth consent screen)
Google replies by giving you a URL (authorizationUrl) where to redirect the user
On that URL, the user is prompted with several information about your application and can grant access.
When the user has granted access, Google will redirect the user to your application success page (callbackUrl) with a unique code.
Using that code, the application can retrieve an access_token, which temporarly lets your application performs requests on behalf of a user.
These steps are a rapid overview of the OAuth-flow, also known as the OAuth dance. To make POST requests to the Google Calendar API, you will have to perform that OAuth dance for every single of your users.
Implementing that flow can be tricky. Fortunately, Google gives very helpful documentation on that. If you don't want to bother, you can also use API-tools (like Pizzly) that takes care of that for you.
What are the security implications of storing a user's unique ID in a cookie?
Logging-in is managed separately. The presence or abscense of this cookie is simply used to determine:
Is this a returning user?
If so, who did this user last login as.
These are all merely hints, the user doesn't get any more rights (before login) than a first-time visitor to the site.
Background
My web app front-end is implemented in Angular4 and backend is all APIs and stateless. JWTs obtained from Firebase Authentication are used for authentication. As such, when a user arrives on the home page, I have no way of knowing who the user (potentially) is and whether they are logged-in, till the time the user goes to the PWA (at /app).
When the user goes to the home page of my web app, I want the (stateless) server to be able to redirect them to the PWA if they have logged-in in the recent past (say 2 days). This can be achieved simply by the presence/ absence of a cookie, but I would also like to be able to show them a personalised greeting when /app page loads up.
Very open to suggestions for a better way to achieve this.
I'm in the process of building a Google Chrome extension, and have some questions about how to implement security into the application.
I need to access a couple of Google API's so am going to be using OAuth 2.0 for that. So basically from the extension I know which user is logged into the browser.
My extension then needs to get and post data to my (nodejs) API service. I want to ensure that the user requesting data is the same user that is logged into the browser. Is there any way of using the previous Google authentication process to also authenticate communications between the extension and my API? I dont really want the user to have to log in again, to access my API.
I'm sure I'm missing something simple, and I've not been able to find anything that fits this scenario
Follow the OpenID Connect auth flow and you will get an access_token and an id_token. The acess_token you will use to use to make authenticated requests to Google APIs as usual. The id_token will be used as authentication with requests to your server.
When the requests hit your server you will need to validate the token and you can then use the contents of the id_token to identify the user.
User wouldn't have to login on auth process provided if user is already logged in and you are using a web application flow (not chrome.identity APIs) but user would see the consent screen atleast the first time. However you can skip the account selector screen if you already know the email address by providing &login_hint= parameter.
I'm trying to post to my company page directly from my server, but I have a hard time understanding how the authentication works. All examples + the documentation seem to require you to have a callback where the "visitor" is promted with a form to confirm the access. But in my case, my app is supposed to only post to my company page and I didn't plan on building a gui at all.
I have setup the Client Id and Client Secret in the Linkedin developer section.
Even though you are the only one that's going to use the app, you still need to execute the OAuth flow and therefore authorize your own app to use your account. You can use Grant for that.
Another thing to note is how LinkedIn handles scopes. They changed how the permissions work earlier this year, so for certain permission you'll have to submit your app for approval.
Lastly LinkedIn doesn't give you a refresh_token so in order to refresh your access_token once it expires you'll have to use a similar hack as the one I described here for Facebook.