We Keep Coding

AWS Cognito Correct User Flow

I'm trying to migrate my PHP based system to AWS but the biggest thing I'm struggling with is user management/authentication side of things. I've made API Gateways and Lambda functions to get data from my RDS instance and I can use API key or ID token for authentication to protect the data they generate. What I'm really struggling with is the Cognito side of things. In my head, the system would work as follows?
User goes to my website and clicks the login button.
User is redirected to the hosted cognito UI and logs in.
The user is redirected to the chosen page and the id token is displayed in the URL
I use JavaScript to store the ID token in local storage (not sure this is the right way)
I can then pull the ID token out and use it in SDK to run and authenticate my APIs
In PHP I would check the session existed before loading the page to prevent users who aren't logged in accessing my system if the session didn't exist they would be redirected to the login page. How do I do this with Cognito/JWT, do I need to verify the JWT with a Lambda function at the top of every HTML page for my site? I basically want to only allow users who are signed in via Cognito user pool to have access to all the HTML, js, CSS files of my system, except the home page.

It sounds like you have most of the cognito stuff worked out.
If you are calling the api gateway from the web client, you are most likely passing that jwt token in the header and those api calls will fail before the user logs in.
If you are using a client side framework (React, Vue, etc), then you probably have access to a router that renders various UI components. This works analgously to what you do on the server in php, and it's pretty easy to lock down certain routes or the rendering of certain components based on a user being logged in. Doing it without a framework will probably require a significant amount of effort.
You can also stand up a php server, validate the jwt token and do what you normally do for authenticated users.
Or you could take the hyper-modern, serverless approach. You could host your html/css in an S3 bucket and put a Cloudfront distribution in front of that. You could write some Lambda#Edge functions to enforce permissions on the content in the S3 bucket.
Likely, if you are creating an api based javascript application you won't need to protect your markup/css.

Error while Single Sign On(SSO) via Azure AD Authentication - AADSTS50059

Error AADSTS50059: No tenant identifying information found in either the request or implied by any provided credentials.
We have two subdomains(sd1.domain.com and sd2.domain.com) registered to two different AAD apps(client id: sd1 and client id: sd2) under the same tenant. We have configured SSO for the angular apps hosted on both the subdomains.
Scenario: When I login to both the subdomains and then logout from one of the subdomain(lets say sd1) and try to refresh the page in the other subdomain(sd2),the authentication is failing with the above specified error.
Further Understanding
Q1 As we have both the AAD's under the same tenant. Is somehow the cookie generated by one AAD affecting the other AAD. If so what is being overwritten / invalidated / deleted.
I have read that that during SSO's first login an authentication cookie is given out by the authentication server and on top of that every site the SSO works on the authentication is done with the help of this cookie and a corresponding site cookie is also generated.Reference
Q2 What and where is the authentication cookie during the SSO mechanism with Azure AD? I can look at two cookies one stored in local storage()
and another
r
Q3
I get it that SSO is used to login to various apps at the same time and a single logout would log us out of all apps but consider I have office and devops at two different subdomains. It does not mean that if I logout of office that I get logged out of devops as well right..
How can we achieve this using the configuration of two AAD's under the same tenant?

Q1 As we have both the AAD's under the same tenant. Is somehow the cookie generated by one AAD affecting the other AAD. If so what is being overwritten / invalidated / deleted.
When you sign out from the first app, the SSO cookie is removed from AAD.
This means the Azure AD session is no longer active.
Q2 What and where is the authentication cookie during the SSO mechanism with Azure AD? I can look at two cookies one stored in local storage()
You need to look at cookies when you are in the Azure AD domain.
That's your app's local storage and cookies, not Azure AD's.
Q3 I get it that SSO is used to login to various apps at the same time and a single logout would log us out of all apps but consider I have office and devops at two different subdomains. It does not mean that if I logout of office that I get logged out of devops as well right..
Yeah well, that's how single sign-on works.
If you tell Azure AD to sign you out, it'll kill your session, which will affect all apps that depend on that session being active.
How can we achieve this using the configuration of two AAD's under the same tenant?
Firstly, you have two apps in your Azure AD tenant, not "two AADs".
To keep your session active in an application even if the AAD session is removed,
your app needs to keep its own session and not depend on AAD after authentication.
So after authentication, your application back-end could issue a cookie or token and your front-end should then use that with calls to the back-end.
If you need to get Azure AD access tokens as the user, you can use refresh tokens to get them from a back-end.
But for front-end apps, there is really no way to get access tokens on behalf of a user without an active AAD session.
And you can't get tokens "as the app" from a front-end app, since there is no way to authenticate the app.
So it depends.
In your scenario, you may be able to keep a session within your app if you want to disconnect it from Azure AD.
But usually SSO is expected to work the way it did.
The point is that it is easy to log out from all your services.

How to authenticate a react-native app offline

Am trying to make an app that runs both online and offline but i want my user to be authenticated or to be logged in once. So after the initial login i want them not to be able to see the login form again, i want to show them a new part of the app. They should be only to see the login form only when they decide to logout. My problem is that it would have been easier for me to do this if they are always online but they might be offline too so i just need them to login once and next time they boot up the app they wont see the login form again rather they would see something else.

There is no authentication offline. Authentication is made so that the server-side makes sure it is used by a given identity because you can never trust the client-side. If there is no server-side, there is no authentication process.
If you just want to let the user use your application, even though he is online, why don't you store a local copy of the user profile within the local storage after a successful authentication? (with only non critical data of course).
This way, your application can rely on its memory to fetch the user profile and not the server while it is offline.

You could save an kind of "userIsAuthenticated"-Flag to local storage (see https://facebook.github.io/react-native/docs/asyncstorage.html).
Based on this flag you could decide which screen the user see on startup.
But be aware, it could drive your Users crazy, if they have allways to relogin, if the network-connection (maybe cause of bad 3g/4g) was Interrupted.
You also give a notice if a user is offline, that they have to be online to use this app.
BTW: To request if a user has Network-Connection you can use: http://facebook.github.io/react-native/releases/0.48/docs/netinfo.html#netinfo.
Don't forget to set permissions in AndroidManifest.xml to be allowed to use the request.

Maintain login state om chrome packed app

I am creating chrome app, I would like my users to login or create a user when they first enter the application.
The goal:
Maintaining login state on chrome packed app.
The problem:
Cookies - Chrome packed app have no cookie API, meaning that "document.domain" exists,
But you can't set cookies, at least not using http request.
Extension- There is not access to browser extensions (for a non-sandbox pages)
Couldn't think on other solution, Any idea?

You could store the session id in the application storage via chrome.storage.local.set chrome.storage.local.get methods.

Single page apps: auth token management and browser refreshes

When working on an Angular app, I have a single page app that communicates with a JSON web service for data.
A "login" in my Angular app is really just exchanging a username/password for a token. That token is passed as a header on all subsequent requests so the server can authorize them. This works great until the users refreshes their browser window of course (via refresh or leaving the "page" and returning).
Obviously one option would be to make the user enter their username/password again, but that seems like a good way to not have any users.
I can think of 4 options:
Store token in a secure session cookie. (What I'm doing now. I am only using so the client can read. Not used or wanted on the server.)
Store token using local storage of some kind. (Would be insecure and
require manual expiration maintenance.)
Prevent user from refreshing browser with some "onbeforeunload"
code. (I don't like when I get the "are you sure you want to leave
this page" messages and I assume others feel the same.)
Include token as part of url. (Could make url's look big and messy. Possible physical security risk. Might make for extra work with bookmarking and expired tokens.)
Is option 1 the best option for this functionality? Is there something better to do than all of these?

I think option 1 is the best one for your use case. All major web frameworks have support for this option.
In case you need to handle this manually you need to ensure these steps:
The web service will process the initial authentication request by creating and setting a secure authentication cookie. The auth cookie should be time based(only valid for a specific time interval) and its value should be a unique value if possible;
After the initial authentication request all subsequent requests will pass the authentication cookie with the request header automatically - this is handled by the browser.
The web service needs to handle cookie based authentication on subsequent requests by validating the cookie value and returning an error if the cookie has expired.
You need to ensure a client side global authentication handler captures any authentication exceptions and displays a friendly message to the user.