I am creating a website that contains a bracket system for a Rocket League tournament. I have set up OpenID for Steam, so that handles PC users. However I am trying to branch out to the console communities. Is there a way I can use OpenID to allow a user to sign into my website with their PSN login?
I mainly just need their ID to keep track of their scores, but if I can get a
PSN API to work with an OpenID login it would be fantastic!
Thanks in advance?
See:
http://www.programmableweb.com/api/psn-sign
This may be what you need:
This API allows people to use the Playstation Network SignIn for their
own sites. If a developer's site URL is allowed by Sony, they can set
their site as the returnURL by GET. This allows them to bypass Sony's
official External PSN Sign In page. The site forwards to a developer's
site on a successful sign in with a sessionId by GET. There is no
official public API to convert the sessionId into a user specific
value (like the PSN-ID). The API converts a valid sessionID into a
proper PSN-ID.
You didn't say what did you try so far so I don't know it you already tried that or not.
Related
I have an OpenID Connect provider built with IdentityServer4 and ASP.NET Identity, running on let's say: login.example.com.
I have a SPA application running on let's say spa.example.com, that already uses my OpenID Connect provider to authenticate users through login.example.com and authorize them to access the SPA.
I have a mobile app (native on both platforms) that is using a custom authentication system at the moment.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
So I started by looking on the OpenID connect website and also re-reading the RFC6749, after a few google searches I realized that was a common problem and I found RFC8252 (OAuth2 for Native clients), also Client Dynamic Registration (RFC7591) and PKCE (RFC7636).
I scratched my head about the fact that it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised.
I disscussed the topic with some co-workers and we came out with the following set-up:
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Use an AuthenticationCode flow for both clients and enforce them to use PKCE.
Use a redirect_uri on the app associated domain say: https://app.example.com/openid
Make the user always consent to log-in into the application after log-in, because neither iOS or Android would bring back the application by doing an automatic redirect, it has to be the user who manually clicks the universal/app link every time.
I used AppAuth library on both apps and everything is working just fine right now on test, but I'm wondering:
Do you think this is a secure way to prevent that anyone with the right skills could impersonate my apps or by any other means get unauthorized access to my APIs? What is the current best practice on achieving this?
Is there any way to avoid having the user to always "consent" (having them to actually tap the universal/app link).
I also noted that Facebook uses their application as a kind of authorization server itself, so when I tap "sing-in with facebook" on an application I get to a facebook page that asks me if I would like to" launch the application to perform log-in". I would like to know how can I achieve something like this, to allow my users login to the SPA on a phone by using my application if installed, as facebook does with theirs.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
This is what OAuth 2.0 and OpenID Connect provides you. The ability to use single user identity among different services. So this is the correct approach .!
it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised
Correct. From OAuth 2.0 specification perspective, these are called public clients. They are not recommended to have client secrets associated to them. Instead, authorization code, application ID and Redirect URL is used to validate token request in identity provider. This makes authorization code a valuable secret.!
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Not a mobile expert. But yes, custom URL domains are the way to handle redirect for OAuth and OpenID Connect.
Also usage of PKCE is the correct approach. Hence redirect occur in the browser (user agent) there can be malicious parties which can obtain the authorization code. PKCE avoid this by introducing a secret that will not get exposed to user agent (browser). Secret is only used in token request (direct HTTP communication) thus is secure.
Q1
Using authorization code flow with PKCE is a standard best practice recommended by OAuth specifications. This is valid for OpenID Connect as well (hence it's built on OAuth 2.0)
One thing to note is that, if you believe PKCE secret can be exploited, then it literally means device is compromised. Think about extracting secret from OS memory. that means system is compromised (virus/ keylogger or what ever we call them). In such case end user and your application has more things to be worried about.
Also, I believe this is for a business application. If that's the case your clients will definitely have security best practice guide for their devices. For example installation of virus guards and restrictions of application installation. To prevent attacks mentioned above, we will have to rely on such security establishments. OAuth 2.0 alone is not secure .! Thats's why there are best practice guides(RFC68129) and policies.
Q2
Not clear on this. Consent page is presented from Identity Provider. So it will be a configuration of that system.
Q3
Well, Identity Provider can maintain a SSO session in the browser. Login page is present on that browser. So most of the time, if app uses the same browser, users should be able to use SPA without a login.
The threat here comes from someone actually installing a malicious app on their device that could indeed impersonate your app. PKCE prevents another app from intercepting legitimate sign in requests initiated from your app so the standard approach is about as safe as you can make it. Forcing the user to sign in/consent every time should help a bit to make them take note of what is going on.
From a UX PoV I think it makes a lot of sense to minimize the occasions when the browser-based sign in flow is used. I'd leverage the security features of the platform (e.g. secure enclave on iOS) and keep a refresh token in there once the user has signed in interactively and then they can sign in using their PIN, finger print or face etc.
We are developing a hybrid mobile application and for certain function calls, there is a url called. Here is a sample request for getting user information
http://someurl.com/1234/account
where: 1234 - is the user id in the database.
We figured that a "man in the middle attack" is possible for this. The url called by the mobile app can be sniffed, then the hacker just changed the value for the user id and with that he can see information for other users. The question is - would simply changing the url called to https solve this security flaw?
No, it will not. You are exposing user data based on an unauthenticated URL and it is trivial for unauthorized parties to access modified URLs even away from the mobile platform.
You all know this page.. Is there ANY way to customize this page somehow?
I thought using an iframe and custom the HTML but Google won't let
me embed their websites..
I thought using a Google Site and inserting a login gadget but there
is no login gadget.
What I want is a custom page where my clients can login to their gmail, drive....
What I want it's not impossible, this guys http://www.cloudcodes.com/custom-login-page.html offers you the possibility to custom the login page and even redirect you to another page after you've logged in.
Directly editing the native login page at accounts.google.com is not possible.
However, for Google Apps accounts, you have the option to set up the Single Sign On service, which allows you to authenticate through a third party provider (Or yourself, if you have the ability). What GControl are offering is this service, although they've labeled it misleadingly, to make you believe your actually editing the login page, rather than redirecting your users to a secure login.
They do it very well though, leveraging the Google Apps APIs to allow you to write and setup the service in their own console.
Source: I installed the service and tried their free trial, and they simply used the APIs to enable SSO on my domain.
Edit for clarity: SSO setup is not available for consumer Gmail.com accounts.
I am developing a chrome plugin which allows the users to email any web content from a html page. For that, I need to use the google authenticator api to allow users to log into their google accounts for sending emails. The OAuth2.0 specs require the redirect_ui parameter which is the url to be called after google authenticates the user. My question is whether it is possible to skip this parameter. I don't want the plugin to be hosted anywhere. I am thinking that it would be hosted locally on the user's machine.
Thanks in Advance.
Google has made a library specifically for using OAuth in Chrome extensions. You can check out the tutorial here.
In case someone stumbles upon this answer in 2017+, extensions (in Chrome and FF) now have a chrome.identity API.
It takes care of the OAuth dance for you, and provides you with a virtual redirect address https://<your-extension-id>.chromiumapp.org/ that will be intercepted by the browser. That way, you can provide a redirect URL without hosting anything.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.