In addition to the authentication techniques that are based on “something you have”, “something you know” and “something you are”, authentication techniques that consider “somewhere you are” are also used. Why? Does it add further security?
“Somewhere you are” is NOT an authentication factor, despite what you might have read elsewhere. It is an authorization factor.
Indeed, it does not answer the question "are you who you claim to be?", but instead it answers "should you be there? / are you authorized to be here?". (The answer to the question "who are you?" being an identification, yet another category.)
To further clarify (as asked in comments): Owning a badge, a key or knowing a password (a.k.a. a token) can answer the question "are you who you claim to be?" because the token should unique and should be in its owner possession. Whereas multiple different persons can easily be in front of the door trying to enter.
If in your very specific case, only authenticated persons can be in front of the door, this only means that the authentication has been performed elsewhere beforehand and that you trust this specific location to be a good conveyor of the authentication information. It also implies that you trust this first authentication method. Whether this trust is misplaced or not depends on your threat model.
As a side note: biometrics should only be considered an identification factor (or a most a very weak authentication factor), because you cannot revoke a biometric feature, while you can revoke a stolen authentication factor, by changing the lock or updating the whitelist. End of side note.
This means in practice that you should check the "somewhere you are" factor (IP address, geo-localization, time-locatization (date expiration), etc.) independently of authentication, and preferably after a proper authentication to be able to log the activity and be able to do accountability.
So yes, you can use the “somewhere you are” factor on top of the classical 3 types of authentication factors, but not as another authentication factor, but as an authorization parameter. Whether it's useful depends on the use-cases, and other answers to this question address this point or give examples.
"Where you are" can be defined in many useful ways.
For instance, location can be determined to be within a certain building. This is useful when it is a work account where you should only be logging in from that building. So, if you are logging in from the building's network, then there is a level of trust that the person logging in is, at least, physically present, and the threat of unauthorised access is extremely limited.
It can also be defined at the country level. If you are providing a country-specific service or all employees/users are expected to be logging in from a specific country, then any logins from beyond that country are suspicious.
Many businesses have used "geo-fencing" for years to block access from geographic areas that are not expected, which is an inverse form of geographic authentication. Using location as a positive factor in authentication is just a natural extension of this.
Note that location is not a strong factor, since it is possible to route traffic to different locations in order to log in from an acceptable location.
Implied authentication with other factors
One use case of "somewhere you are" is in scenarios where being "somewhere" implies that certain other authentication measures have been applied.
For example, you might have a computer system where you authenticate with a username and password (i.e. only "something you know") but that is only accessible from specific workstations in a secure location where entering that location generally requires ID verification. In that sense, being in that place implies (though not necessarily ensures) that both "something you have" and "something you are" factors have also been verified.
Enforced circumstances of access
In certain situations "somewhere you are" adds extra security by ensuring that the access happens in a specific physical environment.
You might have a confidentiality need to prevent the user from copying certain data that they are authorised to access - for example, taking exams, where you want to prevent people from copying and sharing the exam questions. You can solve that by ensuring that access is possible only from a location where the actions of the user are physically monitored, and the user will be prevented from (for example) using their cell phone to take photo of the screen, or even bringing in such devices to the place from which access is allowed.
For another example, you might want to ensure non-repudiation of access (i.e. false claims of stolen credentials) by video recording the person accessing the system. I have seen such measures used in server colocation facilities - if physical presence is required for certain actions, you can note the person who actually accessed the systems and what systems were accessed.
Deterrence due to risk of being caught
Many authentication systems have low consequences for failed attempts to falsely authenticate, so this allows attackers to try authenticating even if there's a low chance of success. However, if "somewhere you are" is a factor, that place can be chosen to ensure that a failed attempt to present false credentials is likely to result in the attacker being detained. This also reduces the likelihood of attacks since many potential attackers would be deterred by this risk.
Answer was posted as comment. I am claiming no reputation score
From a fraud perspective it could help. For example your bank, if you always make payments from country X and all of a sudden they (the bank) see you're making payments from country Y, they could add an extra challenge (SMS code for example) to verify it is most likely you
And here is an extra. When you swipe/touch your credit card, the bank knows where the merchant is. Assuming you use your own card yourself (e.g. never lend to your children/partner, which is not that bad of an idea), and assuming you do have a banking app installed, the bank may either push a geolocation request to your phone, or analyse your location history reported by the app (the second being more privacy-invasive).
Then the bank can compare the approximate distance between POS and mobile device. Precision depends on a number of factors (their mileage may vary), but swiping a card in Bruxelles when the phone is geolocalized in Prague is a red flag!
My bank, for example, asks for the second. To collect 24/7 location information.
The geolocation criteria is only a feature from the point of view of fraud classification, which is normally scored across several parameters (frequency, amount, merchant category, usage of PIN...).
What can realistically happen is that you may get a phone call "Hello Mr. Smith, this is Alice from ABC Bank, your account no. ends with #123 and I am calling to report unusual activity with your card".
Where you are not, is just as important of a concept as where you are. If I login from Romania, what are the odds that it's me? I could be on vacation, could be using a proxy, but the last 500 logins came from Ohio, so is there a reason to think it may not be me? How often do you reject phone calls, because you don't recognize the phone number? What are the odds that 1-800 number is your buddy down the street, if someone calls from an 800 number and says they are your grandson and asks you to wire them some money, does the 800 number play a part? My brain tells me yes. Academia tells me possibly no. Philosophy tells me it shouldn't.. but this is survival so the brain wins.
Like any authentication factor, it only "adds further security" when implemented correctly. There are a myriad of uses, but if done incorrectly it can make no difference, or worse, leave your system less secure.
While outdated (2011), this quick overview gives a nice example of location based authentication:
Location-based authentication rarely comes up, but it has been used with dial-up remote access as an additional authentication factor. Imagine that Joe is authorized to work from home using a dial-in remote access connection to connect to work-based resources. The remote access server can be configured so that as soon as Joe calls in and authenticates, the server hangs up and calls Joe’s computer at home.
As long as Joe tries to connect from his home computer, the connection will work. However, if an attacker was trying to impersonate Joe using Joe’s username and password, the attacker could not connect. Instead, when the attacker authenticated with Joe’s credentials, the remote access server would hang up, and try to call Joe’s computer.
There are many other use case examples, many outlined in other answers already so I won't repeat.
This Wikipedia page on location based authentication is also good for additional reading, or this similar page more broadly covering multi-factor authentication. Specifically notice the use of GPS mentioned in the mobile phones section.
I previously mentioned it could make your authentication less secure. As an (over the top, obviously dumb) example, assume you trust location completely and as long as a user has logged in once before, and they're connecting from the same IP address, they don't need to reauthenticate. As IP addresses are trivial to spoof in 99% of cases, this makes targeting anyone's account child's play.
I include the example to stress that the answer to your question of "How “Somewhere you are” authentication adds further security?" is "Differently depending on how you use it, and only if you implement it correctly".
as @DanChase points out, a simple thing to keep in mind during implementation is to only ever exclude access based on location as an additional factor, never use location as a reason to grant access.
Somewhere you are basically based on the location where the service is authenticated.
One of the most common methods of detecting a user’s location is via Internet Protocol (IP) addresses. For instance, suppose that you use a service that has Geolocation security checks. When you configure your account, you might say that you live in the United States. If someone tries to log in to your account from an IP address located in Germany, the service will probably notify you saying that a login attempt was made from a location different than yours. That is extremely useful to protect your account against hackers.
As noted in A. Heresen's answer, location isn't an authentication factor but instead an authorisation factor.
For me, it's important in several ways in the modern, mobile thing we all have now - firstly if you're simply not expecting a login to occur for User A outside of your country then you can highlight such an occurrence as a high-risk login and take different steps.
You can also look at location vs. time. What I call "time travel". If I log in from an external IP at 13:00 UTC in London and 13:05 UTC from an external IP in New York then at least one of those logins is possibly compromised. That's an obvious "red alert" factor that could be used to mark my account as probably compromised right? Even if I actually have traveled from New York to London, a login that occurs in New York while I'm not there is of some concern.
More than that, you could be a bit more subtle and record location history and require more stringent login if I'm logging in from an untrusted location or one that I don't normally log in from. For example, you might say you don't require MFA for login attempts coming from inside your corporate network, "occasional" MFA for login attempts coming from networks I commonly use, and MFA for every login coming from an untrusted network I don't normally use.
You could combine that with other factors. If I login from my "normal" phone that I normally use that you've fingerprinted but from a coffee shop geographically near where I normally work from home, the chances are that I've probably just nipped out for a coffee and maybe got a call to check something. We'll say that's a medium risk login for argument's sake.
If a new device uses my credentials from a place halfway across the country then that connection attempt sounds like a high risk login.
Now if you can profile all these factors and route me through different authentication requirements based on risk then you've put stuff like location data to good use I'd say.
Another issue not yet mentioned is that "where you are" checks may impede certain forms of man-in-the-middle attacks, especially with things like self-activating security tokens. If e.g. a phone is supposed to automatically grant access to something in a room X if it is within range, without the operator having to manually operate the phone, but attackers set up radio repeaters between room X and room Y, then attackers might wait in room X for the victim to visit room Y. If the phone encrypts its location as part of its transmission, a device in room X could reject any access requests from a phone whose reported location would be too far away from the device to see anyone who might be trying to access it.
In such a scenario, what's being confirmed wouldn't be so much authentication nor authorization, but rather intention. Does the fact that the user has placed the phone within range of a radio repeater that in room Y imply an intention to unlock something in room X? Probably not.
Note that unless the communications medium either securely encrypts parameters necessary for proper reception and retransmission of the raw data (as would be the case for some spread spectrum radios, but wouldn't be the case for many others), or the software imposes sufficiently tight round-trip timing constraints that a message-forwarding system would be unable to meet them, normal methods of man-in-the-middle prevention would be ineffective since the attack doesn't involve eavesdropping or message tampering, but instead simply involves accurate conveyance of messages between the victim and the device.