# Automatic authentication from many different URIs **URL:** \ **Category:** SSO\ **Created:** [31 مايو 2016، 3:17ص UTC](https://meta.discourse.org/t/automatic-authentication-from-many-different-uris/45018 "2016-05-31T03:17:41Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\ **Post date:** [31 مايو 2016، 7:02ص UTC](https://meta.discourse.org/t/automatic-authentication-from-many-different-uris/45018/2 "2016-05-31T07:02:31Z")
Your suggested approach would work well enough, although as you say, it’s a security risk (especially having presumably the same key in _so_ many places, with presumably varying degrees of administrative competence). You’d also have to write a custom plugin for Discourse to implement such a scheme, which may or may not be something you want to delve into. Another option, which isn’t necessarily any “safer” but does allow you to use a stock Discourse instance, would be to implement an oauth2 provider external to Discourse, which itself knew all about whatever custom auth protocol you cooked up. This would remove the need to muck with the Discourse internals, and might give you more flexibility in what you could do, auth-wise. For instance, you might be able to have instances of your app “register” itself with your auth service, and negotiate some sort of per-instance unique shared key, to prevent the need to have one shared key globally. Once you’ve got all the instances registered, you can start doing callback-based verification, too. One thing to bear in mind if you do this is username collisions. I can imagine two users named “john” on different instances of your app, causing Confusion and Delay when they both try to use your Discourse instance… --- _[View the full topic](https://meta.discourse.org/t/automatic-authentication-from-many-different-uris/45018)._